I don’t know about you but as soon as you hear the word Kerberos, I immediately want to shy away. For it sounds complicated and scary but what is it? Well, in simple terms, it’s a modern authentication that can allow organisations to reduce the reliance on passwords on Windows devices.

Why might you need it?

Imagine a world where you’d like to have Entra ID /Azure AD joined devices, authenticating back to on-premise resources. As long as you have hybrid user identities sync’d via AD sync connect, you can have just that but what if you wish to make use of Windows Hello for Business? Then you’ll start to run into some problems and users will be prompted for re-authentication. Why, well the on-premise resources, don’t trust your WHfB authentication token. This is where Cloud Kerberos trust comes to aid. It allows for WHfB configured devices to access on-premise resources without re-authentication and provide a secure authentication trust between Entra ID and the on-premise AD.

Alternatives

As with everything, in short Yes there are but I’d consider these older technology. You have the choice of using a key trust or certificate trust. With the later, even if you have your own PKI infrastructure, I still wouldn’t recommend it. It’s much harder to upkeep and to be honest, it’s a royal pain, comes with poor user experience (at step up stage) and doesn’t really offer anything else for the complexity that it brings. MIcrosoft themselves, recommend Cloud Kerberos Trust!

So how does it work?

What are the supported scenarios?

So imagine, you’re moving to the cloud. Existing devices are hybrid domain joined. New pilot devices are Entra joined via Windows Autopilot and you’re slowly moving workloads over from on-premise. How does this fit? Well in short, it supports both. So you can deploy CKT, deploy one configuration to devices or users and it’ll, well just work!

Devices do need support Windows Hello for business for all this to work but that comes down to the device. I’ll let you research this part!

How to deploy it…

This comes in two parts, setting up the kerberos trust and deploying Windows Hello configuration. Do not deploy the Windows Hello configuration to devices or users, until the Cloud Kerberos configuration is in place. Doing so will mean that users will need to delete their WHfB and start again for it to take place.

Set up Cloud Kerberos Trust

Step 1 - First, ensure TLS 1.2 for PowerShell gallery access.

1

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

Step 2 - Install the AzureADHybridAuthenticationManagement PowerShell module.

1

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Step 3 - Create the new Entra ID Kerberos Server object in Active Directory

1
2

$GAUser = "PlaceYourAdminCreds@tenantdomain.com"
Set-AzureADKerberosServer -Domain $env:UserDNSDomain -UserPrincipalName $GAUser

Step 4 - Now you’re done but lets verify it

1

Get-AzureADKerberosServer

You should see something like this…

If you look on a domain controller within Users and Computer, you should see 2 new objects created. These act like a read only domain controller. They provide the mechanism to provide part of the Primary Refresh Token (PRT) that users need to authenticate.

Do not delete/move/rename these 2 objects. To do so will break your new Cloud Kerberos Trust!

Intune Configuration

1. Create Windows Hello for Business Configuration Profile

Now it’s time to create and deploy the WHfB configuration. Here is an example settings catalog profile to deploy WHfB will all the necessary settings. Make amendments as you see fit, the important one is highlighted in yellow. Use Cloud Trust for on prem auth, just make sure that’s enabled!

2. Deploy it to users or devices. Once the user logs back into the device, they should receive a message to setup Windows Hello.

User Setup

This works in the exactly the same way as it would without kerberos trust so the user won’t notice anything different. They sign in, go through the MFA Prompt and setup faceID, fingerprintID and then a PIN code. Once set, they’ll be logged in and WHfB will be the new default sign in option.

This is one of the biggest benefits of using this method. Whereas using a key trust or certificate trust, means that when a user sets up for the first time, they can’t immediately start using it, they have to wait upwards of 60 mins for the device objects in Active Directory to be updated. Not the case with Cloud Kerberos Trust. Use it straight away!

User Experience.

I’m not going to give you a screen shot of the setup process or accessing on premise file shares. As long as the user has line of sight to the file share, to test Cloud Kerberos, have them sign in with WHfB on the device and access a file share. If it just opens, success! If it prompts for a username/password, we have problems! I’d run the Get-AzureADKerberosServer to check the status.

Thanks for reading!