How To Guide: Deploying Windows Hello for Business Cloud Kerberos Trust

Solution Overview

Windows Hello for Business is a solution that allows enterprise users to replace password-based sign-in with a more preferred strong authentication mechanism. Signing into Windows is simplified for the user as they can leverage fingerprints, iris, facial recognition or a pin code while the organization benefits from the increased security of a strong authentication process where a password is no part of the equation.

The easiest way for an organization to adopt Windows Hello for Business is to deploy the necessary client policies after hybrid-joining or natively joining Azure Active Directory from their Windows 10/11 endpoints. Without Azure Active Directory, deploying Windows Hello for Business in an on-premises only environment requires quite a bit of additional infrastructure and setup such as an enterprise PKI, an Active Directory Federated Services (ADFS) deployment, etc. If a Windows device is hybrid-joined or pure Azure Active Directory joined, deploying the Windows Hello for Business policy settings are all that’s required from the enterprise IT infrastructure perspective to get started.

After Windows Hello for Business is setup for the enterprise clients and users have registered their credentials on devices, they can begin using the new strong authentication methods for logging into Windows.

If users are only accessing cloud-based resources such as OneDrive, SharePoint Online, Teams, etc., you should be all set with no additional setup required. However, if your users will continue to access any on-premises, Active Directory-backed resources such as file shares, print shares, etc., your environment will need a bit more setup. This is where the cloud Kerberos authentication comes into play.

Without additional configuration of the on-premises Active Directory environment, a user who has logged into Windows with Windows Hello for Business credentials and attempts to access an AD-protected resource will be greeted with the following prompt for re-authentication:

This prompt is because the user does not have a ticket-granting-ticket (TGT) from Kerberos for on-premises authentication. When the client attempts to obtain a TGT from a domain controller, they are prompted for authentication. This process can be automated/hidden from the user by deploying one of the following solutions:

• Cloud Kerberos trust deployment – the recommended deployment model when compared to the key trust model. It is also the preferred deployment model if you do not need to support certificate authentication scenarios. No additional on-premises infrastructure is required.
• Key trust deployment – An enterprise PKI is required as trust anchor for authentication. Domain controllers require a certificate for Windows clients to trust them.
• Certificate trust deployment – An enterprise public key infrastructure (PKI) is required as trust anchor for authentication. Domain controllers require a certificate for Windows clients to trust them. The enterprise PKI and a certificate registration authority (CRA) are required to issue authentication certificates to users. Hybrid certificate trust deployment uses AD FS as a CRA.

This article will focus on deploying the recommended Cloud Kerberos trust model. In this model, Azure AD Kerberos is leveraged to grant requested TGT’s for clients accessing on-premises AD protected resources. With the security exchange happening between the client and the device trusted Azure AD directory, no user prompts for authentication arise and the client obtains the necessary TGT to authenticate to the on-premises Active Directory backed resource.

After enabling Azure AD Kerberos in a Windows Server Active Directory domain, you will see an AzureADKerberos computer object when browsing the domain controllers container in Active Directory Users and Computers tool.

This computer object is required for Azure AD to generate the TGT’s mentioned previously, and functions like a Read Only Domain Controller (RODC). Now, let’s dive into the deployment!

Deployment Prerequisites

• Azure AD Multifactor Authentication
• Windows 10 21H2 or later
• Windows 11 or later
• Windows Server 2016 or later domain controllers
• Microsoft Intune or another modern device management platform for deploying the Cloud Kerberos trust policy settings

Important note: users that are directly or indirectly nested in any privileged groups in Active Directory will not be able to use Cloud Kerberos authentication. You should not be using privileged user accounts to log into Windows endpoints as a best practice.

Deploy Azure AD Kerberos

1. Download and install the Azure AD Kerberos PowerShell module. You can do this by opening a Windows PowerShell prompt, running as an administrator:, and running the following:
   • First, ensure TLS 1.2 for PowerShell gallery access: [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
   • Install the Azure AD Kerberos PowerShell Module: Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
2. Create a Kerberos Server object by running the following script from Microsoft and providing credentials when prompted:

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory global administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Global Administrators group for Azure AD.'

# Enter a domain administrator username and password.
$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group.'

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

3. Verify the successful creation of the Azure AD Kerberos Server by running the following command: Get-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred 

In this guide, I’m going to assume you’ve already deployed Windows Hello for Business via either the tenant-wide settings or via individual policies deployed to clients. If you haven’t done either, this is the time to configure it. Since this is impactful for the user, it’s highly advisable to prepare users for the registration process and how Windows Hello for Business will operate. I highly advise against simply flipping the solution on in production without planning the end user rollout.

Deploy Cloud Kerberos Trust Settings to Clients

You will now need to deploy additional Cloud Kerberos trust policy settings to clients via modern device management policy deployment and OMA-URI settings. Here are the instructions for the process via Microsoft Intune:

• Create a new Windows device-based profile. For profile type, select Templates and then select the Custom template.

• Provide the profile with a name and description, then click Next.
• On the configuration settings page, add a new configuration with the following values:
  • Name: Windows Hello for Business Cloud Kerberos Trust
  • Description: Enable Windows Hello for Business cloud Kerberos trust for sign-in and on-premises SSO
  • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<TENANT ID>/Policies/UseCloudTrustForOnPremAuth <TENANT ID> should be replaced with your Azure AD Tenant ID.
  • Data Type: Boolean
  • Value: True

• Click Save, then Next to continue.
• Target the Windows devices that have been enabled for Windows Hello for Business for the new policy and complete the new policy wizard.

After devices receive the updated Windows Hello for Business Cloud Kerberos trust settings, users will no longer be prompted for authentication when accessing on-prem AD protected resources while signed in with Windows Hello for Business credentials!

Did you find this particular article extra helpful? Please consider donating to help me offset the costs of maintaining this site. Your support is greatly appreciated!