Windows Hello for Business Cloud Trust

Windows Hello for Business Cloud Trust

We have a lot of customers who use Windows Hello for Business Azure AD joined Key trust. But now that Windows Hello for Business cloud trust is available (preview), we expect to see a move towards Cloud Trust, maybe this could also be interesting for your setup?

Key trust is rather complicated because you need PKI infrastructure and the solution also rely on Azure AD connect synchronization, Cloud trust on the other hand is so much simpler.

And with devices only joined to Azure AD it gets even more complicated.

But let us have a look at why Cloud Trust is such a good idea.

In this example we use an Azure AD joined only Windows 10 device, with Windows Hello for Business configured for PIN login.

On a device not setup with Cloud Trust or Key Trust, we try to get access to a SMB share, where the user has access.

Because we have not setup Cloud Trust or Key Trust, we will be prompted for credentials.

If we try the same but this time from a client with Cloud Trust enabled, we will get instant access as desired.

Windows Hello for Business cloud trust will give us access to a simplified solution that will allow password less SSO using Windows Hello for Business. The solution also support migration from Key trust to cloud trust and uses Kerberos as part of the solution.

Cloud trust is, as already stated, so much easier to deploy because it does not require your own PKI infrastructure and does not rely on synchronization.
So let us test the setup needed.

Prerequisites

  • Multi-factor Authentication
  • Fully patched Windows 10 version 21H2 or fully patched Windows 11
  • Fully patched Windows Server 2016 or later Domain Controllers
  • Azure AD Kerberos PowerShell module
  • Device management

You can find more information I the documentation Link

Azure AD Kerberos

We then need to setup a Kerberos server object in AD.

This is done with the following PowerShell commands (when executed from a domain joined device with domain administrator privileges).

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Install-Module -Name AzureADHybridAuthenticationManagement
Set-AzureADKerberosServer -Domain "yourdomain.local" -UserPrincipalName "admin@yourtenant..com"

This will create the following object in the Domain Controllers OU.

It will appear as a Read Only Domain Controller (RODC) object, but it is not associated with a physical server.

It will be used to generate TGTs for Active Directory.

You can find more information regarding this part in the following Link.

Configure Using Intune

Then we need to configure our clients, in this example we will create a policy enabling Windows Hello for Business (disabled by default in this tenant) and a policy for Cloud Trust itself.

Hello for Business will be enabled with the following configuration from the Settings catalog.

Cloud Trust can right now only be enabled using an OMA-URI setting, so let us create custom profile.

We will name it Cloud Trust in this example.

Select Add to enter the setting.

And then enter the following settings:

Name: “Windows Hello for Business cloud trust” you choose
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/tenant ID/Policies/UseCloudTrustForOnPremAuth
Data type: Boolean
Value: True

Tenant ID must be replaced with the tenant ID for your Azure AD tenant

Deploy both profiles to the desired targets.

These settings can also be deployed using GPO 😊

User PIN setup

As soon as our policies are in place the user will be required to setup PIN.

Next step will be the MFA step – remember that this is a requirement.

After successfully MFA, the user can enter the desired PIN.

And we are all set.

Sign-in

Once PIN has been setup, we can use it for sign-in. But note that on Hybrid Azure AD joined devices, first use of the PIN requires line of sight to domain controller. But in this test the device is Azure AD joined only.

After sign-in we can access the share as we already seen (line of sight to server needed).

Log

We can see the status in Event viewer Applications and Services Logs – Microsoft – Windows – User Device Registration as shown here:

Testing on Hyper-V

If you test on Hyper-V, remember to not use an Enhanced session when entering PIN.

Key rotation

The Azure AD Kerberos Server encryption krbtgt keys should be rotated on a regular basis, and can be done with the following PowerShell command (when executed from a domain joined device with domain administrator privileges):

Set-AzureADKerberosServer -Domain "yourdomain.local" -UserPrincipalName "admin@yourtenant.com" -RotateServerKey

Azure AD Kerberos Server Object

We can view the Azure AD Kerberos Server by PowerShell using the following command:

Get-AzureADKerberosServer -Domain "yourdomain.local" -UserPrincipalName "admin@yourtenant.com"

And finally, we can remove it as well using the following PowerShell command:

Remove-AzureADKerberosServer -Domain "yourdomain.local" -UserPrincipalName "admin@yourtenant.com"

Happy testing 😊

Table of Contents

Share this post
Search blog posts
Authors
Modern Workplace consultant and a Microsoft MVP in Enterprise Mobility.
Modern Workplace consultant and a Microsoft MVP in Windows and Devices for IT.

Infrastructure architect consultant with focus on Endpoint Management and Microsoft Sentinel.

Infrastructure architect with focus on Modern Workplace and Microsoft 365 security.

Passionate IT professional with 20+ experience in IT architecture, consulting, and design. 

Cloud & security specialist with focus on Microsoft backend products and cloud technologies.

Infrastructure architect with focus on design, implementation, migration and consolidation.

Infrastructure consultant with focus on cloud solutions in Office365 and Azure.

follow us in feedly
Categories

Follow on SoMe