One of the biggest challenges that organizations can face is how their employees handle security protocols. Many will admit that some of the greatest vulnerabilities can come from something as avoidable as simple reused passwords for multiple scenarios. By doing this, individuals will not only leave themselves exposed to attacks but will put the entire organization’s network at risk as well.
This type of challenge is precisely what Microsoft is trying to address with Windows Hello. It gives individuals a simpler but significantly more secure option to access various platforms. In this particular blog, I want us to take a look at how Windows Hello and Cloud Kerberos Trust can provide organizations with better security solutions.
Introducing Windows Hello
For the benefit of those who may not yet be familiar with this service, let’s start by going over what Windows Hello is. As already mentioned above, how users access various platforms is something that can create vulnerabilities in an organization’s network.
So, with Windows Hello, Microsoft is giving us a biometrics-based solution that gives Windows 10 or Windows 11 users the option to sign in to their devices, apps, and networks using a fingerprint, iris scan, or facial recognition. The great thing about this solution is that it gives users a more personal way to authenticate access and offers enterprise-grade security but eliminates the need to type in a password.
Expectedly, some users worry about access to their biometric data by third parties. Fortunately, Windows assures us that your data continues to be highly encrypted and secure. Also, it does not leave your device nor is it stored anywhere else. And as long as you have a compatible device with the necessary hardware, getting started is easy. This is because there is a wizard that will teach the device to recognize your biometric credentials.
You will, however, need to set up a PIN as a backup in case any of the biometric authentication measures happen to fail. Simply put, Windows Hello provides a simple but highly secure authentication service that can also ease concerns about typing in passwords or using sign-in gestures in public.
Windows Hello for Business
Now that we’ve gone over what Windows Hello is, let’s take a look at how it differs from Windows Hello for Business (WHfB). In the simplest of terms, WHfB has all the features of Windows Hello as well as other more advanced ones. Whereas Windows Hello is more suited to the home environment, WHfB, as the name suggests, intends to suit businesses.
For the configuration of WHfB, you can use either a GPO or MDM. Also, Windows Hello for Business uses a PIN backed by an asymmetric key pair or certificate-based authentication. Eliminating the use of use hashes and thus the transmission of passwords means that security is significantly better. And if you want to use the asymmetric key, you’ll require Azure AD or the implementation of a Windows Server 2016 domain controller.
What is Cloud Kerberos Trust?
With the development of Windows Hello for Business Cloud Kerberos Trust, Microsoft is aiming to provide Windows Hello for Business with a simple passwordless experience. The objective is to also avail the service to new or existing Windows Hello for Business deployments. One of the key things about Windows Hello for Business Cloud Kerberos Trust is that it leverages Azure AD Kerberos. Doing it this way means that you create a simpler deployment as compared to the key trust model:
- In this scenario, the deployment of a public key infrastructure (PKI) or changing an existing PKI becomes unnecessary.
- Additionally, synchronizing public keys between Azure AD and Active Directory for users to access on-premises resources also becomes unnecessary.
- Lastly, the deployment of passwordless security key sign-in becomes something that you can do with very little extra setup.
Therefore, with all these potential benefits, Microsoft advises that Windows Hello for Business Cloud Kerberos Trust be the recommended deployment model when compared to the key trust model. And for clients that do not need to support certificate authentication scenarios, this is also the most recommended deployment model.
Azure AD Kerberos and Cloud Kerberos Trust authentication
When it comes to requesting Kerberos ticket-granting-tickets (TGTs) for on-premises authentication, we find that certificate authentication-based Kerberos features usage by both key trust and certificate trust. And when performing this type of authentication, there are two requirements to meet.
- PKI for DC certificates,
- End-user certificates for certificate trust.
In the case of Cloud Kerberos Trust, by using Azure AD Kerberos this negates the need for a PKI to request TGTs. Also, these TGTs can be issued for one or more AD domains by Azure AD for Azure AD Kerberos. And then as far as Windows is concerned, when authenticating with Windows Hello for Business it can request a TGT from Azure AD.
Once a TGT has been returned, Windows can then use it for sign-in or to access AD-based resources. However, it’s worth noting that Kerberos service tickets and authorization will still remain under the control of on-premises domain controllers.
With an enabled Active Directory domain, an Azure AD Kerberos server object will then be created in the domain and it will:
- Not associate with any physical servers but will, however, still appear as Read Only Domain Controller (RODC) object.
- Be solely used by Azure AD to create TGTs for the Active Directory domain. Furthermore, the Azure AD Kerberos Server object must adhere to the same rules and restrictions applied to RODCs.
It’s important to note, though, that there is something to consider before implementing the Cloud Kerberos Trust deployment model. You have to first verify that each of the Active Directory sites where users will be authenticating with Windows Hello for Business has enough read-write domain controllers.
Prerequisites
| Requirement | Notes |
| Multi-factor authentication | There are a few options that you can use to meet this requirement. These include: Ø Azure AD multi-factor authentication Ø multi-factor authentication is provided through AD FS or any other comparable solution. |
| Windows 10, version 21H2, or Windows 11 and later | For clients that are using Windows 10 21H2, they will need to check that they have KB5010415 installed. And then those using Windows 11 21H2, need to have KB5010414 installed. Also, when it comes to Azure AD-joined and Hybrid Azure AD-joined devices, expect to find no Windows version support difference. |
| Windows Server 2016 or later Domain Controllers | For clients that are using Windows Server 2016, they will need to check that they have KB3534307 installed. And then for those using Windows Server 2019, KB4534321 must be installed. |
| Azure AD Kerberos PowerShell module | This is the module that will be necessary for the enabling and management of Azure AD Kerberos. You can find it through the PowerShell gallery. |
| Device management | The management of Windows Hello for Business Cloud Kerberos Trust can be done in a couple of ways: Ø using group policy, Ø using mobile device management (MDM) policyYou will need to enable this feature using policy because it comes disabled by default. |
Authentication to on-premises resources
For authentication to on-premises resources to work properly, Cloud Kerberos Trust will need to be enabled for the concerned user. Once enabled, if you attempt to access domain resources, the process will begin with the device receiving a name hint from metadata in the PRT. Then, a DC locator will find a valid DC before a partial TGT from Azure AD Kerberos is sent with a TGS_REQ to this valid DC. After this, a partial TGT validates and then a TGT is returned. However, the user will still need to be synchronized from Active Directory. And this is an important step that allows us to find the domain name associated with the user, in the event of ticket requests from the KDC.
Azure Active Directory
When it comes to Azure AD-joined devices, authentication to Active Directory will only begin when a particular user tries to access a resource that requires Kerberos authentication. At this point, the Kerberos security support provider will then leverage metadata from the WHfB key in order to get a hint of the user’s domain.
Once the hint is available, the provider can then use a DC locator to find a 2016 domain controller. A domain hint is absolutely necessary for the DC locator. And this will be obtained from the onpremisedomainname that you get with the PRT. Next, the client will get a Domain Controller returned for the continuation of normal service ticket issuance.
The Kerberos provider will then forward a partial TGT,, obtained from Azure AD from a prior Azure AD authentication with the domain, controller once an active 2016 domain controller is found. On this partial TGT, signed by Azure AD Kerberos, all you will get is the user SID. It will be the role of the domain controller to check the validity of the partial TGT. If the process has been successful, the KDC will then send a full TGT to the client after which the client can request service tickets.
Deployment process
To complete the deployment of Windows Hello for Business Cloud Kerberos Trust, there are two steps to follow:
- Set up Azure AD Kerberos.
- Configure a Windows Hello for Business policy and deploy it to the devices.
Deploy Azure AD Kerberos
For those who have already deployed on-premises SSO for passwordless security key sign-in, you should be aware that this means that Azure AD Kerberos is already deployed as well in your hybrid environment. So, this negates the need to redeploy or change your existing Azure AD Kerberos deployment to support Windows Hello for Business. If you haven’t done so, however, you can find the instructions in this section Enable passwordless security key sign-in to on-premises resources by using Azure AD.
Configure Windows Hello for Business policy
Once you have the Azure AD Kerberos object set up, you’ll need to enable Windows Hello for Business Cloud Kerberos Trust on your Windows devices. To configure your devices using Microsoft Intune you can follow the instructions below.
Intune policies can configure Windows Hello for Business if the devices are already under Intune management. You have several options available to you if you want to enable and configure Windows Hello for Business in Intune:
- Devices enrolled in Intune can have a tenant-wide policy applied to them. However, this policy can only be applied at enrolment time. So any changes that are later made to its configuration will not apply to already enrolled devices. This is precisely why, most of the time, you’ll find this policy disabled. And then WHfB can be enabled using a policy targeted to a security group.
- A device configuration policy can be applied as soon as the device is enrolled in Intune. If you make any changes to the policy, these will only apply to the devices during regular policy refresh intervals. You get several policy types that you can choose from:
Ø Custom policy, via the PassportForWork CSP
Ø Identity protection policy template
Verify the tenant-wide policy
If you want to verify exactly which Windows Hello for Business policy was applied at enrollment you can follow the steps below:
- Navigate to the Microsoft Intune admin center and sign in.
- Select Devices > Windows > Windows Enrollment.
- Select Windows Hello for Business.
- Now you can check the status of Configure Windows Hello for Business as well as any other configurable settings.
Enable Windows Hello for Business
Windows Hello for Business is configurable using an account protection policy and to do so you can follow the steps below:
- Navigate to the Microsoft Intune admin center and sign in.
- Select Endpoint security > Account protection.
- Select + Create Policy.
- If you want to go with Platform then you should select Windows 10 and later. But if you want Profile then you should select Account protection.
- Select Create.
- Decide on a Name and then, optionally, a Description > Next.
- If you go and select Disabled under Block Windows Hello for Business, you’ll be able to see multiple available policies.
It’s important to note that these policies are optional to configure, but the recommendation is to configure Enable to use a Trusted Platform Module (TPM) to Yes.
- Under Enable to certificate for on-premises resources, select Not configured.
- Select Next.
- You’ll also have the option to add scope tags and select Next.
- Assign the policy to a security group that contains as members the devices or users that you want to configure > Next.
- Go over the policy configuration again and if satisfied select Create.
Configure the Cloud Kerberos Trust policy
If you want to configure the Cloud Kerberos Trust policy, you can do so using a custom template. Also, this configuration is done separately from enabling Windows Hello for Business. The configuration process should follow the steps below:
- Navigate to the Microsoft Intune admin center and sign in.
- Select Devices > Windows > Configuration Profiles > Create profile.
- For Profile Type, select Templates and select the Custom Template.
- Next, you need to provide a name for the profile. Ideally, this is something simple such as “Windows Hello for Business Cloud Kerberos Trust.
- Then, head over to Configuration Settings where you’ll need to add a new configuration with these settings:
Ø Name: Windows Hello for Business Cloud Kerberos Trust or something else similarly simple
Ø Description (optional): Enable Windows Hello for Business Cloud Kerberos Trust for sign-in and on-premises SSO
Ø OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<tenant ID>/Policies/UseCloudTrustForOnPremAu
(This tenant ID will need to be replaced with the tenant ID for your Azure AD tenant)
Ø Data type: Boolean
Ø Value: True
Ø The final step requires you to assign the policy to a security group whose members are the devices or users that you want to configure.
A very important thing that you need to be aware of is that you will first need to ensure that the Use certificate for on-premises authentication policy is not configured on all the machines that you want to enable Cloud Kerberos Trust. The reason for this is that if you enable this policy then certificate trust will take precedence over Cloud Kerberos Trust.
Provision Windows Hello for Business
When it comes to the provisioning of Windows Hello for Business, the process will begin once a user has signed in. That is, of course, if they meet all the prerequisites. In cases where Cloud Kerberos Trust is enabled by policy on Hybrid Azure AD-joined devices, then Windows Hello for Business Cloud Kerberos Trust will also perform a prerequisite verification.
And if you want to view the status of the prerequisite check you can navigate to User Device Registration admin log under Applications and Services Logs > Microsoft > Windows. Alternatively, you can also view this information from a console by using the dsregcmd /status command.
During a Cloud Kerberos Trust prerequisite check, the system will be looking to pick up whether the user has a partial TGT before the provisioning process proceeds. And the importance of this check is to validate whether Azure AD Kerberos is set up for the user’s domain and tenant.
Upon completion of the check and verification of the Azure AD Kerberos setup, the user can then receive a partial TGT during sign-in with one of their other unlock methods. There are three possible states that you can encounter during the check: Yes, No, and Not Tested. You will see the Not Tested state in a couple of situations:
- Cloud Kerberos Trust is not being enforced by policy
- The device is Azure AD joined
However, please note that Azure AD-joined devices will not have the Cloud Kerberos Trust prerequisite check performed on them. Users can still sign in on Azure AD-joined devices even if Azure AD Kerberos is not provisioned. But, they won’t have SSO to on-premises resources secured by Active Directory.
PIN setup
Once a user completes the sign-in process, the process for enrolling in Windows Hello for Business begins and happens as follows:
- The user will see a full-screen page appear prompting them to use Windows Hello with the organization account. They can then proceed to select OK.
- Next up in the process will be the multi-factor authentication portion of the enrollment. The user will then receive notification that the system is trying to contact them through their configured form of MFA. And without the success, failure, or timing out of the authentication, the provisioning process cannot proceed. If the MFA fails or times out, the user faces an error and see a request to retry.
- Once there is a successful MFA, the user will then be asked to create and validate a PIN. This PIN needs to adhere to the complexity policies that may be set on the device.
Sign-in
Signing in can be done as soon as the user has finished setting up a PIN with Cloud Kerberos Trust. For those using Hybrid Azure AD joined devices there will need to be a line of sight to a DC when the PIN is first used. However, after this initial sign-in or unlocking with the DC, the system will leverage cached sign-in for subsequent unlocks without line of sight or network connectivity.
Migrate from key trust deployment model to Cloud Kerberos Trust
Occasionally, there may be situations where someone may have deployed Windows Hello for Business using the key trust model, but is now looking to migrate to the Cloud Kerberos Trust model. To do so you only need to follow a few simple steps:
- Start by setting up Azure AD Kerberos in your hybrid environment.
- Then you’ll need to enable Cloud Kerberos Trust via Group Policy or Intune.
- Also, you’ll need to first sign out and sign in to the device using Windows Hello for Business when it comes to hybrid Azure AD joined devices.
When signing in for the first time, users of hybrid Azure AD joined devices must sign in with new credentials while having line of sight to a DC.
Migrate from certificate trust deployment model to Cloud Kerberos Trust
An important thing to note is that when moving from certificate trust deployment to a Cloud Kerberos Trust deployment, you’re not going to find a direct migration path. So, if you want to migrate to Cloud Kerberos Trust the Windows Hello container will first need to be deleted. For users that are interested in using the Cloud Kerberos Trust model but had initially deployed Windows Hello for Business using the certificate trust model, they will need to redeploy Windows Hello for Business. The steps to do that are given below:
- To begin the process, the certificate trust policy will need to be disabled.
- With that done you must then leverage either Group Policy or Intune to enable Cloud Kerberos Trust.
- The next step involves the removal of the certificate trust credential using the command certutil -deletehellocontainer from the user context.
- Sign out and sign back in.
- Lastly, you can now provision Windows Hello for Business using the method that is best for you.
And similar to the previous scenario, when signing in for the first time, users of hybrid Azure AD joined devices must sign in with new credentials while having line of sight to a DC.
How Azure AD Kerberos enables access to on-premises resources
Kerberos TGTs can be issued for one or more of your Active Directory domains by Azure AD. The benefit of this feature is that it enables users to sign in to Windows with modern credentials, such as FIDO2 security keys, and then access traditional Active Directory-based resources.
However, your on-premises Active Directory DCs will retain control over authorization as well as the Kerberos Service Tickets. It’s also going to be in your on-premises Active Directory instance where Azure AD Kerberos Server objects will be created and subsequently securely published to Azure AD. These objects have no links to any physical servers. They are only resources that can be used by Azure Active Directory to generate Kerberos TGTs for your Active Directory domain.
- Users will first need to sign in to a Windows 10 device with a FIDO2 security key and authenticates to Azure AD.
- Next, Azure AD will go through the directory looking for a Kerberos Server key that matches the user’s on-premises Active Directory domain.
- At this point, a Kerberos TGT will then be generated by Azure AD for the user’s on-premises Active Directory domain. There’s no authorization data on this TGT, only the user’s SID.
- The client will now receive the TGT as well as the user’s Azure AD Primary Refresh Token (PRT).
- Then, an on-premises Active Directory DC will be contacted by the client machine in order to trade the partial TGT for a fully formed TGT.
- The client machine is now able to access both cloud and on-premises resources because of the Azure AD PRT and full Active Directory TGT that it has obtained.
Requirements
There are a few prerequisites that need to be met if you are to proceed. And these are:
- All concerned devices need to have Windows 10 version 2004 or later.
- All Windows Servers will need to have Windows Server 2016 or later and have patches installed for Windows Server 2016 and Windows Server 2019.
- AES256_HMAC_SHA1 must be enabled when Network security: Configure encryption types allowed for Kerberos policy is configured on domain controllers.
- You need to have the necessary credentials to carry out the steps in the scenario:
Ø an Active Directory user who is a member of the Domain Admins group for a domain and a member of the Enterprise Admins group for a forest. Referred to as $domainCred.
Ø an Azure AD user who is a member of the Global Administrators role referred to as $cloudCred.
Supported scenarios
In this section, the scenario that we’ll be going over supports SSO in the situations below:
- Cloud resources such as Microsoft 365 and other Security Assertion Markup Language (SAML)-enabled applications.
- On-premises resources, and Windows-integrated authentication to websites. The resources can include websites and SharePoint sites that require IIS authentication and/or resources that use NTLM authentication.
Unsupported scenarios
The scenarios given below will not be supported:
- Windows Server Active Directory Domain Services (AD DS)-joined (on-premises only devices) deployment.
- Remote Desktop Protocol (RDP), virtual desktop infrastructure (VDI), and Citrix scenarios by using a security key.
- S/MIME by using a security key.
- Run as by using a security key.
- Log in to a server by using a security key
Install the Azure AD Kerberos PowerShell module
Admins will be glad to know that there are FIDO2 management features provided for them by the Azure AD Kerberos PowerShell module.
- To begin, you’re going to need to use the Run as administrator option to open a PowerShell prompt.
- Next, you need to install the following Azure AD Kerberos PowerShell module:
# 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 AzureADHybr
Something that you should be aware of is that the Azure AD Kerberos PowerShell module uses the AzureADPreview PowerShell module to provide advanced Azure AD management features. For those that already have the Azure AD PowerShell module installed on the local computer, there could be a conflict that would result in the failure of the installation.
So, if you want to avoid any such conflicts then you need to include the “-AllowClobber” option flag. The Azure AD Kerberos PowerShell module can be installed on any computer from which you can access your on-premises Active Directory DC. And this can happen without having to depend on the Azure AD Connect solution.
Furthermore, you’ll find that the Azure AD Kerberos PowerShell module is distributed through the PowerShell Gallery. What this Gallery will provide is a central repository for PowerShell content. If you are looking for useful PowerShell modules containing PowerShell commands and Desired State Configuration (DSC) resources then this is the place to find them.
Create a Kerberos Server object
Once you have completed the installation of the Azure AD Kerberos PowerShell module, admins can now use it to create an Azure AD Kerberos Server object in their on-premises directory. You’ll now need to perform the following for each domain and forest in your organization that contains Azure AD users:
- To begin, you’re going to need to use the Run as administrator option to open a PowerShell prompt.
- Next, there will be some PowerShell commands that are used for creating a new Azure AD Kerberos Server object both in your on-premises Active Directory domain and in your Azure Active Directory tenant that you will need to run. You can find examples of these prompts on this page.
View and verify the Azure AD Kerberos Server
At this point, you may want to check that everything that you’ve done has come out the way it’s supposed to. So, to check out the Azure AD Kerberos Server that you’ve been working on, you can use this command:
Get-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
By using this command, you’ll be able to see the properties of the Azure AD Kerberos Server. Doing so allows you to verify these properties and determine if this was the result you were looking for.
Running against another domain by supplying the credential will connect over NTLM, and then it fails. The issue can be resolved for users in the Protected Users security group in Active Directory by following these steps:
- Navigate to ADConnect and sign in as another domain user
- Don’t supply “-domainCredential”
The user that’s already signed in is the one whose Kerberos ticket is going to be used. However, you need to verify whether the user has the required permissions in Active Directory to execute the previous command and you can do so by executing whoami /groups.
VERIFYING PERMISSIONS
| Property | Description |
| ID | Refers to the unique ID of the AD DS DC object. Occasionally, you will find this ID called slot or its branch ID. |
| DomainDnsName | Refers to the Active Directory domain’s DNS domain name. |
| ComputerAccount | The computer account object of the Azure AD Kerberos Server object (the DC). |
| UserAccount | Refers to the disabled user account object containing the Azure AD Kerberos Server TGT encryption key. The account’s domain name is given below: CN=krbtgt_AzureAD,CN=Users,<Domain-DN>. |
| KeyVersion | Refers to the key version of the Azure AD Kerberos Server TGT encryption key. The version can only be assigned after the creation of the key and will be incremented each time the key is rotated. Increments are based on replication metadata and are likely greater than one. Please note that you should always ensure that the KeyVersion for the on-premises object and the CloudKeyVersion for the cloud object are the same. |
| KeyUpdatedOn | Simply refers to the date and time of the creation or update date and time of the Azure AD Kerberos Server TGT. |
| KeyUpdatedFrom | The Domain Controller where the Azure AD Kerberos Server TGT encryption key was last updated. |
| CloudId | This is the ID from the Azure AD object and it should also be the same as the ID from the first line of the table. |
| CloudDomainDnsName | Refers to the Azure AD object’s DomainDnsName and it should be the same as the DomainDnsName from the second line of the table. |
| CloudKeyVersion | Refers to the KeyVersion from the Azure AD object which needs to be the same as the KeyVersion from the fifth line of the table. |
| CloudKeyUpdatedOn | Refers to the KeyUpdatedOn from the Azure AD object and it should be the same as the KeyUpdatedOn from the sixth line of the table. |
Rotate the Azure AD Kerberos Server key
Users are advised to regularly rotate the Azure AD Kerberos Server encryption krbtgt keys. And as far as what schedule to follow, it’s recommended that you use the same rotation schedule applied to all the other Active Directory DC krbtgt keys.
Remove the Azure AD Kerberos Server
In some cases, you may need to revert the scenario and remove the Azure AD Kerberos Server from both the on-premises Active Directory and Azure Active Directory. To do so, you can follow the command below:
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey
Multiforest and multidomain scenarios
We find that in Azure AD the Azure AD Kerberos Server object is represented as a KerberosDomain object. And each on-premises Active Directory domain will be represented as a single KerberosDomain object in Azure AD.
Wrap up
Something that should be as simple as a password can create plenty of problems for businesses. If a user forgets a password this will hinder productivity and will cost the business as IT has to come in and resolve the issue. This is just one example of how issues with passwords can be problematic for businesses. And these situations can create vulnerabilities in an organization’s network that can leave them exposed to malicious actors.
As you go over these problems, it’s easy to see why Windows Hello for Business can be just the right tool to address these challenges. It’s a service that offers you a simple but secure way to authenticate identities and thus enhance your overall organizational security. With cyber-attacks becoming more prevalent and sophisticated, solutions like Windows Hello for Business look like the way to go for the future.