Single Sign-on with Windows Hello For business on Azure AD devices using cloud trust

There are a few different ways of getting Single Sign-on (SSO) with Windows Hello For Business (WHfB) up and running for Azure AD devices however in my opinion it has been very complex and the documentation from Microsoft have been hard to get my head around. There are so many different things you need to configure and guides that points to different resources. Just the other month I tried setting up Key trust in my lab envirorment and I was never able to get it working 100% and after many many hours of troubleshooting I just gave up and felt defeated by this freaking SSO……

Cloud trust to the rescue ?
Because of the hardship getting it up and running I kind of ignored it for some time until I discovered there was a new way that from the outside looked a lot simpler to implement and that was Cloud trust and Azure AD kerberos

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module

Cloud trust is currently in public preview and not get general available but it was a perfect oportunity for me to test it out and see if I could get it to work, will I finaly be able to use WHfB and get SSO to my on-prem resources from a Azure AD joined device managed by Intune ? I truly hoped so.

Overview

There’s essentially 2 parts to get the solution up and running.

  1. Create WHfB policy and create a custom OMA-URI to enable Cloud Trust on the device
  2. Implement Azure AD Kerberos Server Keys

Illustration of the Azure AD Kerberos Server implementation from Microsoft.

Requirements for Cloud Trust

RequirementNotes
Multi-factor AuthenticationThis requirement can be met using Azure AD multi-factor authentication, multi-factor authentication provided through AD FS, or a comparable solution.
Patched Windows 10 version 21H2 or patched Windows 11 and laterIf you’re using Windows 10 21H2, KB5010415 must be installed. If you’re using Windows 11 21H2, KB5010414 must be installed. There’s no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices.
Fully patched Windows Server 2016 or later Domain ControllersDomain controllers should be fully patched to support updates needed for Azure AD Kerberos. If you’re using Windows Server 2016, KB3534307 must be installed. If you’re using Server 2019, KB4534321 must be installed.
Azure AD Kerberos PowerShell moduleThis module is used for enabling and managing Azure AD Kerberos. It’s available through the PowerShell Gallery.
Device managementWindows Hello for Business cloud trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy.

Implementation

Microsofts documentation on the actuall implementation is really good and I had no problem following it and get it working on the first try (except for some DNS issues that I cover a bit later but had nothing to do with the implementation it self.) I wont post a compelte step by step guide today since the documentation is that good. However I will just point out some of the main parts below.

Links for Microsoft Documentation.

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises

Azure AD Kerberos

first we need to Install the powershell Module AzureADHybridAuthenticationManagement

https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement

Next step is to Install the Azure AD Kerberos Server.

Once its done you will also find the following disabled accounts in your on-premise AD

If you run Get-AzreuADKerberosServer before setting it up you will find that all the properties are empty like this.

Endpoint Manager – Intune

Windows Hello for Business policy needs to be applied to the device, it does not really matter where that policy comes from and the Microsoft documentation mentions a few different ways. I wont dive in to the specifics in this article other than just mention that my WHfB policy comes from Intune.

On top of that we also need to create a Custom OMA-URI policy to enable the cloud trust on the local device. This is also covered in the Microsoft documentation but here are a few screenshots from my envirorment.

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust#configure-cloud-trust-policy

Don’t forget to change the Tenant ID part of the OMA-URI to your tenant ID.

Name: Windows Hello for Business cloud trust

Description: Enable Windows Hello for Business cloud trust for sign-in and on-premises SSO

OMA-URI: ./Device/Vendor/MSFT/PassportForWork/{Tenant ID}/Policies/UseCloudTrustForOnPremAuth

Data type: Boolean

Value: True

Once created its time to assign the newly created policy to our users or devices.

Experience

The experience for the end-user should be the following: They logon to their device with WHfB and from there they should be able to access on-premise resources that authenticates with Kerberos. In the examples below the user is trying to access a file share and an internal website that both requires authentication.

User Experience: SSO With WHfB – before Cloud trust implementation

User Experience: SSO with WHfB with Cloud trust

SSO with WHfB DNS issue

One problem I ran in to was related to DNS… Its always DNS…

This was a weird one in my opinion because SSO worked fine if you logged on with Username and Password on the device but if you used WHfB you first got promted for the pin which indicates that SSO is not working. After that I got a message that said “We can’t sign you in with this credential becuase your domain isn’t available”

And in Eventvwr on the device I saw Event ID 11 “The Distinguished Name in the subject field of your smart card logon certificate does not contain enough information to identify the appropriate domain on an non-domain joined computer. Contact your system administrator.”

I was able to figure out that the DNS server IP was wrong in my router under DHCP for my lab envirorment and once that was changed it started working perfectly.

That’s it for this time, Don’t forget to follow me on twitter @timmyitdotcom

5 comments

  1. what about azure ad joined vms in same
    vnet as file server? users rdp to them. how do they get sso?

  2. Fantastic guide, why couldn’t Microsoft be like this.
    Skål!

Leave a Reply