mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-15 14:57:23 +00:00
adding troubleshooting docs, fixing related ad fs notes, updating faq, and adding note about KDC auth EKU
This commit is contained in:
Matthew Palko
parent
701382fd5d
commit
97da4680d3
@ -13,7 +13,7 @@ manager: dansimp
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 08/19/2018
|
||||
ms.date: 01/14/2021
|
||||
ms.reviewer:
|
||||
---
|
||||
# Prepare and Deploy Windows Server 2016 Active Directory Federation Services
|
||||
@ -50,9 +50,8 @@ Prepare the Active Directory Federation Services deployment by installing and up
|
||||
> (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
|
||||
> ```
|
||||
> 6. Execute the command `Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'`.
|
||||
> 7. Restart the ADFS service.
|
||||
> 8. On the client: Restart the client. User should be prompted to provision WHFB.
|
||||
> 9. If the provisioning window does not pop up then need to collect NGC trace logs and further troubleshoot.
|
||||
> 7. Restart the AD FS service.
|
||||
> 8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business.
|
||||
|
||||
## Update Windows Server 2016
|
||||
|
||||
@ -218,7 +217,6 @@ Sign-in the federation server with _domain administrator_ equivalent credentials
|
||||
12. When the process completes, click **Close**.
|
||||
13. Do not restart the AD FS server. You will do this later.
|
||||
|
||||
|
||||
### Add the AD FS Service account to the KeyCredential Admin group and the Windows Hello for Business Users group
|
||||
|
||||
> [!NOTE]
|
||||
@ -227,6 +225,7 @@ Sign-in the federation server with _domain administrator_ equivalent credentials
|
||||
The **KeyCredential Administrators** global group provides the AD FS service with the permissions needed to perform key registration. The Windows Hello for Business group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user.
|
||||
|
||||
Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
|
||||
|
||||
1. Open **Active Directory Users and Computers**.
|
||||
2. Click the **Users** container in the navigation pane.
|
||||
3. Right-click **KeyCredential Admins** in the details pane and click **Properties**.
|
||||
@ -246,6 +245,7 @@ Key Registration stores the Windows Hello for Business public key in Active Dire
|
||||
The key-trust model needs Windows Server 2016 domain controllers, which configures the key registration permissions automatically; however, the certificate-trust model does not and requires you to add the permissions manually.
|
||||
|
||||
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
|
||||
|
||||
1. Open **Active Directory Users and Computers**.
|
||||
2. Right-click your domain name from the navigation pane and click **Properties**.
|
||||
3. Click **Security** (if the Security tab is missing, turn on Advanced Features from the View menu).
|
||||
@ -259,6 +259,7 @@ Sign-in a domain controller or management workstations with _Domain Admin_ equiv
|
||||
## Configure the Device Registration Service
|
||||
|
||||
Sign-in the federation server with _Enterprise Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
|
||||
|
||||
1. Open the **AD FS management** console.
|
||||
2. In the navigation pane, expand **Service**. Click **Device Registration**.
|
||||
3. In the details pane, click **Configure Device Registration**.
|
||||
@ -299,6 +300,7 @@ The registration authority template you configure depends on the AD FS service c
|
||||
>Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
|
||||
|
||||
#### Windows 2012 or later domain controllers
|
||||
|
||||
Sign-in a certificate authority or management workstations with _domain administrator_ equivalent credentials.
|
||||
|
||||
1. Open the **Certificate Authority Management** console.
|
||||
@ -321,6 +323,7 @@ Sign-in a certificate authority or management workstations with _domain administ
|
||||
#### Windows 2008 or 2008R2 domain controllers
|
||||
|
||||
Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
|
||||
|
||||
1. Open the **Certificate Authority** management console.
|
||||
2. Right-click **Certificate Templates** and click **Manage**.
|
||||
3. In the **Certificate Template** console, right-click the **Exchange Enrollment Agent** template in the details pane and click **Duplicate Template**.
|
||||
@ -337,6 +340,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
|
||||
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 administrator 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**.
|
||||
@ -358,6 +362,7 @@ Sign-in a certificate authority or management workstations with _domain administ
|
||||
#### Mark the template as the Windows Hello Sign-in template
|
||||
|
||||
Sign-in to an **AD FS Windows Server 2016** computer with _enterprise administrator_ equivalent credentials.
|
||||
|
||||
1. Open an elevated command prompt.
|
||||
2. Run `certutil –dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY`.
|
||||
|
||||
@ -367,6 +372,7 @@ Sign-in to an **AD FS Windows Server 2016** computer with _enterprise administra
|
||||
### Publish Enrollment Agent and Windows Hello For Business Authentication templates to the Certificate Authority
|
||||
|
||||
Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
|
||||
|
||||
1. Open the **Certificate Authority** management console.
|
||||
2. Expand the parent node from the navigation pane.
|
||||
3. Click **Certificate Templates** in the navigation pane.
|
||||
@ -395,6 +401,7 @@ Active Directory Federation Server used for Windows Hello for Business certifica
|
||||
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.
|
||||
|
||||
### Service Connection Point (SCP) in Active Directory for ADFS Device Registration Service
|
||||
|
||||
> [!NOTE]
|
||||
> Normally this script is not needed, as enabling Device Registration via the ADFS Management console already creates the objects. You can validate the SCP using the script below. For detailed information about the Device Registration Service, see [Configuring Device Registration](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn614658(v=ws.11)?redirectedfrom=MSDN).
|
||||
|
||||
@ -440,6 +447,7 @@ Many environments load balance using hardware devices. Environments without har
|
||||
### Install Network Load Balancing Feature on AD FS Servers
|
||||
|
||||
Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
|
||||
|
||||
1. Start **Server Manager**. Click **Local Server** in the navigation pane.
|
||||
2. Click **Manage** and then click **Add Roles and Features**.
|
||||
3. Click **Next** On the **Before you begin** page.
|
||||
@ -455,6 +463,7 @@ Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
|
||||
Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
|
||||
|
||||
Sign-in a node of the federation farm with _Admin_ equivalent credentials.
|
||||
|
||||
1. Open **Network Load Balancing Manager** from **Administrative Tools**.
|
||||
|
||||
2. Right-click **Network Load Balancing Clusters**, and then click **New Cluster**.
|
||||
@ -479,6 +488,7 @@ Sign-in a node of the federation farm with _Admin_ equivalent credentials.
|
||||
## Configure DNS for Device Registration
|
||||
|
||||
Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
|
||||
|
||||
1. Open the **DNS Management** console.
|
||||
2. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**.
|
||||
3. In the navigation pane, select the node that has the name of your internal Active Directory domain name.
|
||||
@ -493,6 +503,7 @@ The Windows Hello provisioning presents web pages from the federation service.
|
||||
### Create an Intranet Zone Group Policy
|
||||
|
||||
Sign-in the domain controller or administrative workstation with _Domain Admin_ equivalent credentials:
|
||||
|
||||
1. Start the **Group Policy Management Console** (gpmc.msc).
|
||||
2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
|
||||
3. Right-click **Group Policy object** and select **New**.
|
||||
@ -559,8 +570,8 @@ Each file in this folder represents a certificate in the service account’s Per
|
||||
|
||||
For detailed information about the certificate, use `Certutil -q -v <certificateThumbprintFileName>` .
|
||||
|
||||
|
||||
## Follow the Windows Hello for Business on premises certificate trust deployment guide
|
||||
|
||||
1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
|
||||
2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
|
||||
3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services (*You are here*)
|
||||
|
||||
@ -0,0 +1,145 @@
|
||||
---
|
||||
title: Windows Hello for Business Deployment Known Issues
|
||||
description: A Troubleshooting Guide for Known Windows Hello for Business Deployment Issues
|
||||
keywords: identity, PIN, biometric, Hello, passport
|
||||
params: siblings_only
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security, mobile
|
||||
audience: ITPro
|
||||
author: mapalko
|
||||
ms.author: mapalko
|
||||
manager: dansimp
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 01/14/2021
|
||||
ms.reviewer:
|
||||
---
|
||||
# Windows Hello for Business Known Deployment Issues
|
||||
|
||||
The content of this article is to help troubleshoot and workaround known deployment issues for Windows Hello for Business. Each issue below will describe the applicable deployment type Windows versions.
|
||||
|
||||
## Hybrid Key Trust Logon Broken Due to User Public Key Deletion
|
||||
|
||||
Applies to:
|
||||
|
||||
- Hybrid key trust deployments
|
||||
- Windows Server 2016, builds 14393.3930 to 14393.4048
|
||||
- Windows Server 2019, builds 17763.1457 to 17763.1613
|
||||
|
||||
In Hybrid key trust deployments with domain controllers running certain builds of Windows Server 2016 and Windows Server 2019, the user's Windows Hello for Business key is deleted after they sign-in. Subsequent sign-ins will fail until the user's key is synced during the next Azure AD Connect delta sync cycle.
|
||||
|
||||
### Identifying User Public Key Deletion Issue
|
||||
|
||||
After the user provisions a Windows Hello for Business credential in a hybrid key trust environment, the key must sync from Azure AD to AD during an Azure AD Connect sync cycle. The user's public key will be written to the msDS-KeyCredentialLink attribute of the user object.
|
||||
|
||||
Before the user's Windows Hello for Business key is synced, sign-in's with Windows Hello for Business will fail with the error message, *"That option is temporarily unavailable. For now, please use a different method to sign in."* After the sync is successful, the user should be able to login and unlock with their PIN or enrolled biometrics.
|
||||
|
||||
In environments impacted with this issue, after the first sign-in with Windows Hello for Business after provisioning is completed, the next sign-in attempt will fail. In environments where domain controllers are running a mix of builds, only some may be impacted by this issue and subsequent logon attempts may be sent different domain controllers. This may result in the sign-in failures appearing to be intermittent.
|
||||
|
||||
After the initial logon attempt, the user's Windows Hello for Business public key is being deleted from the msDS-KeyCredentialLink attribute. This can be verified by querying a user's msDS-KeyCredentialLink attribute before and after sign-in. The msDS-KeyCredentialLink can be queried in AD using [Get-ADUser](https://docs.microsoft.com/powershell/module/addsadministration/get-aduser) and specifying *msds-keycredentiallink* for the *-Properties* parameter.
|
||||
|
||||
### Resolving User Public Key Deletion Issue
|
||||
|
||||
To resolve this behavior, upgrade Windows Server 2016 and 2019 domain controllers to with the latest patches. For Windows Server 2016, this behavior is fixed in build 14393.4104 ([KB4593226](https://support.microsoft.com/help/4593226)) and later. For Windows Server 2019, this behavior is fixed in build 17763.1637 ([KB4592440](https://support.microsoft.com/help/4592440)).
|
||||
|
||||
## Key Trust Authentication Broken for Windows Server 2019
|
||||
|
||||
Applies to:
|
||||
|
||||
- Windows Server 2019
|
||||
- Hybrid key trust deployments
|
||||
- On-premises key trust deployments
|
||||
|
||||
Domain controllers running early versions of Windows Server 2019 have an issue that prevents key trust authentication from working properly. Networks traces report KDC_ERR_CLIENT_NAME_MISMATCH.
|
||||
|
||||
### Identifying Server 2019 Key Trust Authentication Issue
|
||||
|
||||
On the client, authentication with Windows Hello for Business will fail with the error message, *"That option is temporarily unavailable. For now, please use a different method to sign in."*
|
||||
|
||||
This error is usually presented on hybrid Azure AD joined devices in key trust deployments after Windows Hello for Business has been provisioned but before a user's key has synced from Azure AD to AD. If a user's key has been synced from Azure AD and the msDS-keycredentiallink attribute on the user object in AD has been populated for NGC, then it is possible that this error case is occurring.
|
||||
|
||||
The other indicator of this failure case can be identified using network traces. If network traces are captured for a key trust sign-in event, the traces will show kerberos failing with the error KDC_ERR_CLIENT_NAME_MISMATCH.
|
||||
|
||||
### Resolving Server 2019 Key Trust Authentication Issue
|
||||
|
||||
This issue was fixed in Windows Server 2019, build 17763.316 ([KB4487044](https://support.microsoft.com/help/4487044/windows-10-update-kb4487044)). Upgrade all Windows Server 2019 domain controllers to Windows Server 2019, build 17763.316 or newer to resolve this behavior.
|
||||
|
||||
## Certificate Trust Provisioning with AD FS Broken on Windows Server 2019
|
||||
|
||||
Applies to:
|
||||
|
||||
- Windows Server 2019
|
||||
- Hybrid certificate trust deployments
|
||||
- On-premises certificate trust deployments
|
||||
|
||||
AD FS running on Windows Server 2019 fails to complete device authentication properly due to an invalid check of incoming scopes in the request. Device authentication to AD FS is a requirement for Windows Hello for Business to enroll a certificate using AD FS. The client will block Windows Hello for Business provisioning until this authentication is successful.
|
||||
|
||||
### Identifying Certificate Trust with AD FS 2019 Enrollment Issue
|
||||
|
||||
The provisioning experience for Windows Hello for Business will launch if a set of prerequisite checks done by the client are successful. The result of the provisioningAdmin checks is available in event logs under Microsoft-Windows-User Device Registration. If provisioning is blocked because device authentication has not successfully occurred, there will be an event ID 362 in the logs that states that *User has successfully authenticated to the enterprise STS: No*.
|
||||
|
||||
Log Name: Microsoft-Windows-User Device Registration/Admin
|
||||
Source: Microsoft-Windows-User Device Registration
|
||||
Date: <Date and time>
|
||||
Event ID: 362
|
||||
Task Category: None
|
||||
Level: Warning
|
||||
Keywords:
|
||||
User: <User SID>
|
||||
Computer: <Computer name>
|
||||
Description:
|
||||
Windows Hello for Business provisioning will not be launched.
|
||||
Device is AAD joined ( AADJ or DJ++ ): Yes
|
||||
User has logged on with AAD credentials: Yes
|
||||
Windows Hello for Business policy is enabled: Yes
|
||||
Windows Hello for Business post-logon provisioning is enabled: Yes
|
||||
Local computer meets Windows hello for business hardware requirements: Yes
|
||||
User is not connected to the machine via Remote Desktop: Yes
|
||||
User certificate for on premise auth policy is enabled: Yes
|
||||
Enterprise user logon certificate enrollment endpoint is ready: Not Tested
|
||||
Enterprise user logon certificate template is : No ( 1 : StateNoPolicy )
|
||||
User has successfully authenticated to the enterprise STS: No
|
||||
Certificate enrollment method: enrollment authority
|
||||
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.
|
||||
|
||||
If a device has recently been joined to a domain, then there may be a delay before the device authentication occurs. If the failing state of this prerequisite check persists, then it can indicate an issue with the AD FS configuration.
|
||||
|
||||
If this AD FS scope issue is present, event logs on the AD FS server will indicate an authentication failure from the client. This error will be logged in event logs under AD FS/Admin as event ID 1021 and the event will specify that the client is forbidden access to resource 'http<span>://schemas.microsoft.com/ws/2009/12/identityserver/selfscope</span>' with scope 'ugs':
|
||||
|
||||
Log Name: AD FS/Admin
|
||||
Source: AD FS
|
||||
Date: <Date and time>
|
||||
Event ID: 1021
|
||||
Task Category: None
|
||||
Level: Error
|
||||
Keywords: AD FS
|
||||
User: <ADFS service Account>
|
||||
Computer: <Date and time>
|
||||
Description:
|
||||
Encountered error during OAuth token request.
|
||||
Additional Data
|
||||
Exception details:
|
||||
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received invalid OAuth request. The client '38aa3b87-a06d-4817-b275-7a316988d93b' is forbidden to access the resource 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' with scope 'ugs'.
|
||||
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String scopeParameter, String clientId, String relyingPartyId)
|
||||
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()
|
||||
|
||||
### Resolving Certificate Trust with AD FS 2019 Enrollment Issue
|
||||
|
||||
This issue is fixed in Windows Server, version 1903 and later. For Windows Server 2019, this issue can be remediated by adding the ugs scope manually.
|
||||
|
||||
1. Launch AD FS management console. Browse to "Services > Scope Descriptions".
|
||||
2. Right click "Scope Descriptions" and select "Add Scope Description".
|
||||
3. Under name type "ugs" and Click Apply > OK.
|
||||
4. Launch PowerShell as an administrator.
|
||||
5. Get the ObjectIdentifier of the application permission with the ClientRoleIdentifier parameter equal to "38aa3b87-a06d-4817-b275-7a316988d93b":
|
||||
|
||||
``` PowerShell
|
||||
(Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
|
||||
```
|
||||
|
||||
6. Execute the command `Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'`.
|
||||
7. Restart the AD FS service.
|
||||
8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business.
|
||||
@ -14,7 +14,7 @@ metadata:
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 01/12/2021
|
||||
ms.date: 01/14/2021
|
||||
ms.reviewer:
|
||||
|
||||
title: Windows Hello for Business Frequently Asked Questions (FAQ)
|
||||
@ -51,6 +51,12 @@ sections:
|
||||
|
||||
The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
|
||||
|
||||
- question: How does Windows Hello for Business work with Azure AD workplace registered devices?
|
||||
answer: |
|
||||
On Azure AD workplace registered devices, a user will be asked to provision a Windows Hello for Business key if the feature is enabled by mobile device management policy. If the user has an existing Windows Hello container for use with their local or Microsoft connected account, the Windows Hello for Business key will be enrolled in their existing container and will be protected using their exiting gestures.
|
||||
|
||||
If a user has signed into their Azure AD workplace registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
|
||||
|
||||
- question: I have Windows Server 2016 domain controller(s), so why is the Key Admins group missing?
|
||||
answer: |
|
||||
The **Key Admins** and **Enterprise Key Admins** groups are created when you install the first Windows Server 2016 domain controller into a domain. Domain controllers running previous versions of Windows Server cannot translate the security identifier (SID) to a name. To resolve this, transfer the PDC emulator domain role to a domain controller running Windows Server 2016.
|
||||
@ -126,7 +132,7 @@ sections:
|
||||
answer: |
|
||||
Review [Azure AD Connect sync: Attributes synchronized to Azure Active Directory](https://docs.microsoft.com/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](https://docs.microsoft.com/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](https://docs.microsoft.com/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include additional attributes.
|
||||
|
||||
- question: Is Windows Hello for Business multifactor authentication?
|
||||
- question: Is Windows Hello for Business multi-factor authentication?
|
||||
answer: |
|
||||
Windows Hello for Business is two-factor authentication based on the observed authentication factors of: something you have, something you know, and something that's 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. By 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".
|
||||
|
||||
|
||||
@ -13,12 +13,13 @@ manager: dansimp
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 08/19/2018
|
||||
ms.date: 01/14/2021
|
||||
ms.reviewer:
|
||||
---
|
||||
# Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
- Azure Active Directory joined
|
||||
- Hybrid Deployment
|
||||
@ -63,6 +64,7 @@ If your CRL distribution point does not list an HTTP distribution point, then yo
|
||||
> If your CA has published both the Base and the Delta CRL, please make sure you have included publishing the Delta CRL in the HTTP path. Include web server to fetch the Delta CRL by allowing double escaping in the (IIS) web server.
|
||||
|
||||
### Windows Server 2016 Domain Controllers
|
||||
|
||||
If you are interested in configuring your environment to use the Windows Hello for Business key rather than a certificate, then your environment must have an adequate number of Windows Server 2016 domain controllers. Only Windows Server 2016 domain controllers are capable of authenticating user with a Windows Hello for Business key. What do we mean by adequate? We are glad you asked. Read [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
|
||||
|
||||
If you are interested in configuring your environment to use the Windows Hello for Business certificate rather than key, then you are the right place. The same certificate configuration on the domain controllers is needed, whether you are using Windows Server 2016 domain controllers or domain controllers running earlier versions of Windows Server. You can simply ignore the Windows Server 2016 domain controller requirement.
|
||||
@ -73,21 +75,21 @@ Certificate authorities write CRL distribution points in certificates as they ar
|
||||
|
||||
#### Why does Windows need to validate the domain controller certificate?
|
||||
|
||||
Windows Hello for Business enforces the strict KDC validation security feature, which imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business, the Windows 10 client validates the reply from the domain controller by ensuring all of the following are met:
|
||||
Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on an Azure AD joined device, the Windows 10 client validates the reply from the domain controller by ensuring all of the following are met:
|
||||
|
||||
- The domain controller has the private key for the certificate provided.
|
||||
- The root CA that issued the domain controller's certificate is in the device's **Trusted Root Certificate Authorities**.
|
||||
- Use the **Kerberos Authentication certificate template** instead of any other older template.
|
||||
- The domain controller's certificate has the **KDC Authentication** enhanced key usage.
|
||||
- The domain controller's certificate has the **KDC Authentication** enhanced key usage (EKU).
|
||||
- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain.
|
||||
- The domain controller's certificate's signature hash algorithm is **sha256**.
|
||||
- The domain controller's certificate's public key is **RSA (2048 Bits)**.
|
||||
|
||||
Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business does not enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you are adding Azure AD joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the **KDC Authentication** EKU. If you need to update your domain controller certificate to include the **KDC Authentication** EKU, follow the instructions in [Configure Hybrid Windows Hello for Business: Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md)
|
||||
|
||||
> [!Tip]
|
||||
> If you are using Windows Server 2008, **Kerberos Authentication** is not the default template, so make sure to use the correct template when issuing or re-issuing the certificate.
|
||||
|
||||
|
||||
## Configuring a CRL Distribution Point for an issuing certificate authority
|
||||
|
||||
Use this set of procedures to update your certificate authority that issues your domain controller certificates to include an http-based CRL distribution point.
|
||||
|
||||
@ -13,7 +13,7 @@ manager: dansimp
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 08/20/2018
|
||||
ms.date: 01/14/2021
|
||||
ms.reviewer:
|
||||
---
|
||||
# Configure Windows Hello for Business: Active Directory Federation Services
|
||||
@ -76,9 +76,8 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
|
||||
> (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
|
||||
> ```
|
||||
> 6. Execute the command `Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'`.
|
||||
> 7. Restart the ADFS service.
|
||||
> 8. On the client: Restart the client. User should be prompted to provision WHFB.
|
||||
> 9. If the provisioning window does not pop up then need to collect NGC trace logs and further troubleshoot.
|
||||
> 7. Restart the AD FS service.
|
||||
> 8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business.
|
||||
|
||||
### Section Review
|
||||
|
||||
|
||||
@ -13,18 +13,18 @@ manager: dansimp
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 08/19/2018
|
||||
ms.date: 01/14/2021
|
||||
ms.reviewer:
|
||||
---
|
||||
|
||||
# Configure Hybrid Windows Hello for Business: Public Key Infrastructure
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10, version 1703 or later
|
||||
- Hybrid Deployment
|
||||
- Certificate Trust
|
||||
|
||||
|
||||
Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
|
||||
|
||||
All deployments use enterprise issued certificates for domain controllers as a root of trust. Hybrid certificate trust deployments issue users sign-in certificate that enables them to authenticate using Windows Hello for Business credentials to non-Windows Server 2016 domain controllers. Additionally, hybrid certificate trust deployments issue certificate to registration authorities to provide defense-in-depth security for issuing user authentication certificates.
|
||||
@ -37,7 +37,7 @@ This section has you configure certificate templates on your Windows Server 2012
|
||||
|
||||
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.
|
||||
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. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD joined devices. The steps below to *Create a Domain Controller Authentication (Kerberos) Certificate Template* and *Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template* to include the **KDC Authentication** OID in the domain controller certificate may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD joined devices to your environment in the future.
|
||||
|
||||
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 as a baseline to create an updated domain controller certificate template.
|
||||
|
||||
@ -255,7 +255,6 @@ Sign-in to the certificate authority or management workstations with an _Enterpr
|
||||
|
||||
6. Close the console.
|
||||
|
||||
|
||||
#### Unpublish Superseded Certificate Templates
|
||||
|
||||
The certificate authority only issues certificates based on published certificate templates. For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
|
||||
@ -274,8 +273,8 @@ Sign-in to the certificate authority or management workstation with _Enterprise
|
||||
|
||||
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
|
||||
@ -285,7 +284,6 @@ Sign-in to the certificate authority or management workstation with _Enterprise
|
||||
> * 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)
|
||||
@ -295,6 +293,7 @@ Sign-in to the certificate authority or management workstation with _Enterprise
|
||||
<hr>
|
||||
|
||||
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
|
||||
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
|
||||
|
||||
@ -13,18 +13,18 @@ manager: dansimp
|
||||
ms.collection: M365-identity-device-management
|
||||
ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 08/19/2018
|
||||
ms.date: 01/14/2021
|
||||
ms.reviewer:
|
||||
---
|
||||
|
||||
# Configure Hybrid Windows Hello for Business: Public Key Infrastructure
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10, version 1703 or later
|
||||
- Hybrid Deployment
|
||||
- Key trust
|
||||
|
||||
|
||||
Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
|
||||
|
||||
All deployments use enterprise issued certificates for domain controllers as a root of trust.
|
||||
@ -37,7 +37,7 @@ This section has you configure certificate templates on your Windows Server 2012
|
||||
|
||||
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.
|
||||
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. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD joined devices. The steps below to update the domain controller certificate to include the **KDC Authentication** OID may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD joined devices to your environment in the future.
|
||||
|
||||
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.
|
||||
|
||||
@ -113,13 +113,13 @@ Sign-in to the certificate authority or management workstation with _Enterprise
|
||||
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
|
||||
> * Publish Certificate templates to certificate authorities
|
||||
> * Unpublish superseded certificate templates
|
||||
>
|
||||
>
|
||||
> s
|
||||
> [!div class="step-by-step"]
|
||||
> [< Configure Azure AD Connect](hello-hybrid-key-whfb-settings-dir-sync.md)
|
||||
> [Configure policy settings >](hello-hybrid-key-whfb-settings-policy.md)
|
||||
@ -129,6 +129,7 @@ Sign-in to the certificate authority or management workstation with _Enterprise
|
||||
<hr>
|
||||
|
||||
## Follow the Windows Hello for Business hybrid key trust deployment guide
|
||||
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
|
||||
|
||||
@ -66,5 +66,7 @@
|
||||
## [Windows Hello for Business Frequently Asked Questions (FAQ)](hello-faq.yml)
|
||||
### [Windows Hello for Business Videos](hello-videos.md)
|
||||
|
||||
## [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
|
||||
## [Event ID 300 - Windows Hello successfully created](hello-event-300.md)
|
||||
## [Windows Hello for Business Troubleshooting]
|
||||
### [Known Deployment Issues](hello-deployment-issues.md)
|
||||
### [Errors during PIN creation](hello-errors-during-pin-creation.md)
|
||||
### [Event ID 300 - Windows Hello successfully created](hello-event-300.md)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user