Hi all,

This post will be all about Cloud Kerberos trust with Windows Hello for Business with Intune and something called Dual Enrollment…. euh what? Additionally, understanding Cloud Kerberos trust is essential for those navigating modern authentication.

And another euh what? …..Still using Hybrid Entra ID joined Endpoints to get drive mappings to on-prem…. hmmm read further and you will see that i all can be done with Intune and Cloud Kerberos!!

Windows Hello for Business offers a secure and passwordless authentication experience for Windows users. While not brand new, it has become an essential part of modern authentication toolsets. It replaces traditional password sign-ins with strong authentication methods.

A key enhancement to Windows Hello for Business is the cloud Kerberos trust, which simplifies hybrid authentication deployments. This method leverages Microsoft Entra Kerberos to request Kerberos ticket-granting tickets (TGTs). These TGTs facilitate on-premises authentication, streamlining the process significantly.

A deeper dive into Cloud Kerberos trust reveals its pivotal role in ensuring secure access across diverse environments.

One of the main advantages of cloud Kerberos trust over other deployment models is its simplicity. It eliminates the need for a public key infrastructure (PKI) and the synchronization of public keys, making it a more straightforward solution.

When implementing Cloud Kerberos trust, organizations can enhance their security posture and streamline user access.

This guide focuses on the specific configurations for setting up Windows Hello for Business with cloud Kerberos trust. We will start by deploying Microsoft Entra Kerberos, followed by configuring the policy that instructs Windows to use cloud Kerberos trust. Configure a drive mapping policy to an on-prem file share, some tests you can do to check if everything is OK and i will explain something that happened to me in my lab config on which i could not put my finger on straight away.

Configuring Cloud Kerberos trust correctly is crucial for ensuring seamless authentication experiences.

The main reason for this guide is to bundle the confusing Microsoft documentation (again) regarding this topic. And also, it would be a coincidence if i didn’t stumbled upon something that i couldn’t explain in the first test runs. It had something to do with Windows Hello for Business Dual Enrollment….

You can find the Microsoft documentation here:

• Windows Hello for Business cloud Kerberos trust deployment guide – Windows Security | Microsoft Learn
• Passwordless security key sign-in to on-premises resources – Microsoft Entra ID | Microsoft Learn

Also the guys from Intune Training have also a good video on this subject, they also mention the confusing Microsoft documentation a few times 😉 check out there video here.

I will configure this for the most asked question we get: How can we access a shared drive on our on-prem infrastructure (or Azure Storage) with a cloud only or hybrid device.

Leveraging Cloud Kerberos trust can significantly simplify authentication processes in hybrid environments.

A special thanks to Rudy Ooms for providing the Drive Mapping ADMX files. Check out his blog – Home – Call4Cloud – Intune | MMP-C | WinDC | Autopilot Everything about Microsoft 365 and Intune

For efficient management, understanding the implementation of Cloud Kerberos trust is vital for IT professionals.

So let’s started shall we?

Prerequisites Cloud Kerberos trust with Windows Hello for Business

To start we need to have some prerequisites in place of course:

• A DC (server 2016 or 2019 with the latest updates)
• MFA
• AzureAD AD Kerberos powershell module (Download here)
• AD Connect configured (I have User Sync, Password Hash Sync, Password Writeback enabled in my Demo lab)
• A client PC (Windows 10 or Windows 11 with the latest updates)
• An intune license
• A device or VM with a TPM 2.0 chip

The Server Config

Enabling Azure AD Kerberos creates an “Azure AD Kerberos” server object in the domain.

This server object:

• Appears as a Read Only Domain Controller (RODC) object, but isn’t associated with any physical servers.
• Is only used by Azure AD to generate partial TGTs for the Active Directory domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object.

Download and install the Azure AD Kerberos PowerShell module from the link in the prerequisites. Open powershell as admin an enter this code

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

If you want to see all the commandlets in the module use this command:

Get-Command -Module AzureADHybridAuthenticationManagement

Select Azure Cloud (Default is Azure Commercial)

By default the Set-AzureADKerberosSever cmdlet will use the Commercial cloud endpoints. If you are configuring Kerberos in another cloud environment, you need to set the cmdlet to use the specified cloud.

To get a list of the available clouds and the numeric value needed to change, run the following:

Get-AzureADKerberosServerEndpoint

Note the numeric value next to your desired cloud environment. To then set the desired cloud environment, run the following for public:

Set-AzureADKerberosServerEndpoint -TargetEndpoint 0

Now lets create the Active Directory object by using this script:

replace the variables with your own.

# 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 a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"
# Enter a domain administrator username and password.
$domainCred = Get-Credential
# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Now if you check on your DC you will find this computer object:

And this user object:

That’s it for the server config, now let’s see how the config in Intune must be done.

The Intune config

Thus, the integration of Cloud Kerberos trust is essential for organizations seeking reliable authentication solutions.

Different Settings Locations

We can enable Windows Hello for Business in a few places within Intune, a tenant wide setting and an Endpoint Security setting. We will cover the setup with the Endpoint Security setting, with this setting we are more flexible on who we can assign the use of Windows Hello for Business, the tenant wide settings are out of the box assigned to All users. In my demo tenant both where turned on (probably for some old test stuff) and have set the tenant wide back to not configured.

In conclusion, knowing how to configure Cloud Kerberos trust can empower businesses to enhance their security frameworks.

I have created a user group to assign the intune policies: sg-CloudKerberos-WfHB, you can create one or use an existing one.

Endpoint Security Policy

This policy setup will leverage the benefits of Cloud Kerberos trust to secure user accounts.

To configure this policy go to Endpoint Security – Account Protection – Create Policy – Windows 10 and later – Account protection. You can use the settings as in the screenshot if you want. The Block Windows Hello for Business must have a setting of Disabled and the Enable to use a Trusted Platform Module (TPM) has to be set to Yes. All other settings can be configured as per your own needs.

Microsoft has made a change on the policy some time ago. The Block Windows Hello for Business is now Use Windows Hello For Business (User) and must have a setting of True and the Enable to use a Trusted Platform Module (TPM) is now Require Security Device (User) and also has to be set to True. All other settings can be configured as per your own needs.

See the old policy here:

And the new policy here:

Settings Catalog Policy

Make sure to align your organization’s policies with Cloud Kerberos trust for optimal security.

Previously these settings where set by a custom OMA-URI setting, now you can do this with pre-defined settings.

Go to Devices – Windows – Configuration – Create – New Policy – Platform: Windows 10 and later – Profile Type: Settings Catalog – Create – Name your policy e.g. Cloud Kerberos. Click Add settings and select Windows Hello for Business. Make sure you select the same settings as in the screenshot.

Add scope tags if you want and assign the policy to the created group and create the policy.

NOTE: If you still have certificates which are used for authentication you will also need to disable the setting Use Certifcate For On Prem Auth

You can also use this to map drive mappings which reside in Azure. I usually split up these policies but if you need both on-prem and Azure drive mappings you can put it into 1 single policy. For Azure you need to configure a policy like this:

Go to Devices – Windows – Configuration – Create – New Policy – Platform: Windows 10 and later – Profile Type: Settings Catalog – Create – Name your policy e.g. Cloud Kerberos – Azure Authentication. Click Add settings and search for Kerberos. Select Cloud Kerberos Ticket Retrieval Enabled.

Ultimately, deploying Cloud Kerberos trust allows for more secure connections between cloud services and on-premises resources.

If you want to get more info on how to create an Azure file share to map drives to check out this article by fellow MVP Peter Klapwijk here

Basically everything is in place now. As stated in the intro of this guide, the question we mostly get from customers is regarding accessing drive mappings to an on-prem file share. Also this can be achieved with an intune policy. Let’s check out how this works.

Understanding the intricacies of Cloud Kerberos trust is key to improving user access and security.

Create a Drive Mapping policy to On-Prem

The settings to achieve this are not yet included as a setting in intune so we need to import the drive mapping ADMX and ADML files. You can download them here. Extract these files somewhere on your machine. You will also need the Windows ADMX templates, you can find them here:

• Windows 10
• Windows 11

I’ve already described the procedure to install these ADMX files ihttps://www.microsoft.com/en-us/download/details.aspx?id=104677n a previous post which you can find here. Use the same procedure to import the Drive Mapping ADMX files.

To create the policy go to Devices – Windows – Configuration – Create – New Policy – Platform: Windows 10 and later – Profile Type: Templates – Imported Administrative templates (preview) – Create – Name your policy e.g. Map Drive T. Click user configuration and select Network Drive Mappings

Select your drive letter you want to map and fill in the UNC path and enable Display a notification if a mapped drive fails to reconnect

Assign scope tags if you want and assign this policy to a user group, you can use the same group as we used for the previous policies.

Ensure all users understand the importance of Cloud Kerberos trust in the authentication process.

Now the drive mapping will be pushed with intune to the devices and the drive mapping appears in the explorer window and i can access the content.

To create a drive mapping to Azure it is basically the same but instead of the path tho the on-prem file share you use the URL from you Azure storage

Testing

Now when you enroll a device, whether it is a hybrid of a full cloud device you can do the same things to test. Open a powershell window and do the following:

• To query the DNS server for a list of domain controllers type this:

nltest /dsgetdc:"YourFQDN"

As a result you should get this:

• Check the Cloud Primary (Hybrid logon) TGT available count, this must be 1 or greater

klist cloud_debug

As a result you should get this:

• Check for cached tickets

klist

As a result you should get this:

Now to check how your device is joined. 1st let’s check this on an Cloud Only device

dsregcmd /status

You can see that my device is NOT AD or Hybrid AD joined

Now to check how your device is joined on a Hybrid Entra ID joined device

dsregcmd /status

You can see that my device is AD or Hybrid AD joined

With a focus on Cloud Kerberos trust, your organization can streamline user access across platforms.

Furthermore, Cloud Kerberos trust aids in maintaining the integrity of user authentication.

So everything seems fine. However….

These improvements stem from implementing Cloud Kerberos trust effectively in your IT structure.

In summary, Cloud Kerberos trust is a cornerstone for secure and efficient user authentication in modern IT environments.

The Strange Stuff

By prioritizing Cloud Kerberos trust, organizations can enhance their overall security strategy.

I had enrolled 2 VM’s, 1 full cloud another Autopilot Hybrid Entra ID Joined and all was working fine, until…. There where some Windows updates, and no it wasn’t related to the updates. After a reboot i could no longer login on the hybrid device with my pin. Following error message appeared:

This focus on Cloud Kerberos trust will significantly benefit your organization’s security framework.

When i tried to open the mapped drive on my cloud only device it asked me for my pin. so not good. After searching the error message i stumbled upon a 2 year old Reddit article and completely at the bottom of that article it stated this:

Turned out to be that the users not having WHFB working were part of Account Operators Group which is a protected group by AdminSDHolder in Active Directory.

Now some things got a little clearer in my head, however not everything, so i went to google and searched for more information and it led me to a Microsoft article about Dual enrollment. To be honest, i never heard of this before. Here it clearly states that Dual enrollment enables administrators to perform elevated, administrative functions by enrolling both their nonprivileged and privileged credentials on their device.

So i went i had a look on my DC and to my test account that i was using. My test account had the domain admin role so that was the reason that after the reboot i could no longer sign in with my pin on my hybrid device and that on my cloud only device i could no longer access the shared drive.

After i removed my test user from the domain admin group all was working again as it should. Surely I know that you don’t log on to a device with a domain admin user but hey, this is a lab. If that user was NOT a member of the domain admin group i would have never ran into this issue and this blog wouldn’t exist. 😉

So lessons learned again. If you read thru the article there is a solution to get this working with privileged accounts. This is also stated in the article:

As a final test i wiped both devices from the intune portal an re-enrolled them, and now everything was fine, even after the Windows updates and several reboots.

By embracing Cloud Kerberos trust, companies can ensure efficient and safe user authentication across devices.

I hope this post will help you to setup everything and as always if you feel there is something in error or you want to add some stuff from your own experience don’t hesitate to contact me!

Utilizing Cloud Kerberos trust helps businesses navigate the complexities of authentication in today’s digital landscape.

And as always if you feel there is something in error or you want to add some stuff from your own experience don’t hesitate to contact me!