Improving your Windows Hello for Business Hybrid Password less setup by using Cloud Trust

As described in my previous blog, we have implemented Windows Hello for Business Hybrid based on the key-trust model for Hybrid Azure AD Joined and Azure AD Joined devices. This Windows Hello for Business Hybrid key-trust setup will make sure your Windows Hello for Business credentials can be used for on-premises resources as well and don’t get annoying credentials prompts.

As the Windows Hello for Business Hybrid key-trust setup is quite complex to configure and has the problem that an Azure AD Connect synchronization is required to write-back the public key of the Windows Hello for Business enrollment to Active Directory, Microsoft is planning to introduce a new Windows Hello for Business Hybrid concept called cloud trust!

This new cloud-trust model has the advantage that we don’t require a PKI infrastructure, therefore we don’t need to publish the CRL and don’t need to put a certificate on domain controllers. But even more important we can get rid of the synchronization of the public key to Active Directory.

The last point is quite important with new device deployments or re-enrollments in Windows Hello for Business, this as with key-trust we have a dependency on Azure AD Connect which does a write-back of the public key to Active Directory. Therefore, we need to wait for the sync interval to run before we can use the Windows Hello for Business credentials for on-premises resources (by default the synchronization interval of Azure AD Connect is set to 30 minutes).

To summarize in short the reasons why you should move away from Windows Hello for Business key-trust to Windows Hello for Business cloud-trust are:

  • Simple Windows Hello for Business deployment model;
  • No PKI infrastructure is required, meaning no CRL replacement;
  • No Azure AD Connect synchronization dependency for writing back the Windows Hello for Business Public key to Active Directory.
  • No device write-back required (only applicable for cert-trust deployments).
  • No ADFS deployment required (only applicable for cert-trust deployments).

Now you know why you should replace your current setup or build your new setup with Windows Hello for Business cloud trust, lets first have a look at the requirements.

Requirements check-list (per Windows Hello for Business trust model):

Cloud-trustKey-TrustCertificate-Trust
Windows 10 21H2 (with KB5010415 or newer CU) or Windows 11 21H2 (with KB5010414 or newer CU) devices with TPM.Windows 10 & 11 devices with TPMWindows 10 & 11 devices
Synchronized Identities via Azure AD ConnectSynchronized Identities via Azure AD ConnectSynchronized Identities via Azure AD Connect
Windows Server 2016 Domain Controller(s) with patch KB4534307 or newer CU installed, or Windows Server 2019 Domain Controller with patch KB4534321 or newer CU installed.Windows Server 2016 domain controller, at least one on each siteWindows Server 2008 R2 domain controllers
Windows Server 2008 R2 domain and forest functional levelPrimary Domain Controller role hosted on a Server 2016 Domain ControllerWindows Server 2016 Active Directory or later schema
Azure AD Connect version 1.4.32.0 or later (only required for PowerShell tooling)Windows Server 2008 R2 domain and forest functional levelWindows Server 2008 R2 domain and forest functional level
 Certificate Authority based on Server 2012 or higherCertificate Authority based on Server 2012 or higher
 Certificate Revocation List internally accessibleNew KDC certificate deployed to Domain Controllers
 New KDC certificate deployed to Domain ControllersNew WHFB certificate deployed to end user devices
 Root & Intermediate certificates deployed to clientsRoot & Intermediate certificates deployed to clients
  Windows Server 2016 AD FS deployment
  Active Directory being federated with Azure Active Directory via AD FS
  Device write-back option enabled in Azure Active Directory Connect

Now let’s have a look how you can easily migrate away from Windows Hello for Business key-trust and move to Windows Hello for Business cloud-trust.

NOTE: In case you’ve not yet implemented Windows Hello for Business in your environment please read my other blog first.


Windows Hello for Business Hybrid Cloud-Trust Deployment

Step 1: Creating the AzureADKerberos computer object

To deploy the Windows Hello for Business cloud trust model we do require within the Active Directory a server object which can be used by the Azure Active Directory to generate Kerberos TGTs for the on-premises Active Directory domain. This process is described below and is the same as the hybrid deployment for FIDO2 keys.

  1. User signs in to their Windows 10 or 11 device with their Windows Hello for Business credentials and authenticates to Azure AD.
  2. Azure AD checks the directory for a Kerberos server key matching the user’s on-premises AD domain.
    • Azure AD generates a Kerberos TGT for the user’s on-premises AD domain. The TGT only includes the user’s SID. No authorization data is included in the TGT.
  3. The TGT is returned to the client along with their Azure AD Primary Refresh Token (PRT).
  4. The client machine contacts an on-premises AD domain controller and trades the partial TGT for a fully formed TGT.
  5. The client machine now has an Azure AD PRT and a full Active Directory TGT and can access both cloud and on-premises resources.

More information can be found here on the docs as well.

The server object which will be created in Active Directory will always have the name AzureADKerberos and if this object already exists, i.e. for your hybrid FIDO2 setup, the steps around creating this object can be skipped.

NOTE: If the AzureADKerberos object already exists, make sure to plan the rotation of the encryption krbtgt_AzureAD. In a normal circumstance and looking at best practices this should be done every month and can be executed with the AzureADKerberos PowerShell module and the command below from the Azure AD Connect Server in your environment:

Import-Module "C:\Program Files\Microsoft Azure Active Directory 	Connect\AzureADKerberos\AzureAdKerberos.psd1"
# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = Read-Host -Prompt "Enter FQDN of Active Directory Domain"

# Enter an Azure Active Directory global administrator username and password.
$AdminUsername = Read-Host -Prompt "Global Admin username"
$AdminPassword = Read-Host -Prompt "Password" -AsSecureString
$cloudCred = New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $AdminUsername, $AdminPassword

# 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.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -	DomainCredential $domainCred -RotateServerKey -Force

If you have checked the server object AzureADKerberos doesn’t exist in your environment and you made sure the pre-requisites are in place, let’s create the AzureADKerberos object. For that we need to logon to the Azure AD Connect server and execute the PowerShell script below:

NOTE: It’s safe to do this even if the AzureADKerberos object exists, the code and script will handle the scenario and it will not lead to any outage.

Import-Module "C:\Program Files\Microsoft Azure Active Directory 	Connect\AzureADKerberos\AzureAdKerberos.psd1"
# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = Read-Host -Prompt "Enter FQDN of Active Directory Domain"

# Enter an Azure Active Directory global administrator username and password.
$AdminUsername = Read-Host -Prompt "Global Admin username"
$AdminPassword = Read-Host -Prompt "Password" -AsSecureString
$cloudCred = New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $AdminUsername, $AdminPassword

# 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.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

This script will ask to put in your Active Directory domain name, asks for your global admin credentials and your on-premises domain admin credentials.

During the PowerShell script you are prompted with an MFA challenge as well if configured.

Now to verify if the Kerberos Server object is created execute the following PS Command:

# Viewing and verifying the Azure AD Kerberos Server
Get-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

And as you can see the server object has been created beneath the Domain Controllers OU.

Now the AzureADKerberos object is in place let’s look at how we can enable the Windows 10 & 11 clients to make use of this cloud trust deployment.


Step 2: Enable the cloud-trust deployment on your devices

For Azure AD Joined devices

As we have enabled Windows Hello for Business already, as described in this blog, we are just going to put in the settings required to enable cloud trust. For that go to the Microsoft Endpoint Manager console, click on Devices and hit Windows. From there click on Configuration Profiles and hit ‘+ Create Profile’.

On the right side of the screen select as platform ‘Windows 10 and later’, as Profile Type ‘Templates’, now select ‘Custom’ and hit ‘Create’.

NOTE: This setting is currently not available within the settings catalog in Intune, I hope it will be soon.

Give this custom profile a friendly name, i.e. IdentityMan-WHfBCloudTrust, and hit ‘Next’.

In the configuration settings screen hit ‘Add’ and fill in the OMA-URI settings as follows and once done hit ‘Save’.

NOTE: Please replace {yourtenantid} within the OMA-URI below with your tenantid, you can lookup your tenant id here.

Name: WHfB Cloud Trust
Description: Enable / Transform to WHfB Cloud Trust
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/{yourtenantid}/Policies/UseCloudTrustForOnPremAuth
Data type: Boolean
Value: True

Verify the settings and hit ‘Next’.

Make sure the group is assigned to correct group (these are users which are enabled for Windows Hello for Business) and which you either want to move from key-trust to cloud trust or for which you want to enable on-premises access with their Windows Hello for Business credentials.

Now go through the ‘Applicability Rules’ and hit ‘Review + Create’, verify the settings and hit ‘Create’.

NOTE: If you hit clients which don’t support this functionality (i.e. Windows 10 21H1) the feature won’t be enabled and your clients will still use the key-trust model. Besides if you have enabled the ‘Use certificate for on-premises authentication‘ policy, the certificate trust is enforced over the cloud trust (or key-trust) on the client, so if you want to make sure your clients are using cloud trust, please make sure this setting is disabled.

Now the policy is created let’s synchronize the device and verify the deployment status is succeeded from the Microsoft Endpoint Manager console.

Once verified let’s check the event viewer logs on the end users device as well by going to the Event viewer –> Application and Services Logs –> Microsoft –> Windows –> User Device Registration. In here check the latest event and see if ‘Cloud trust for on-premises auth policy is enabled’ is set to ‘Yes’. If so your device is using the cloud-trust model! :-).

Your Azure AD Joined devices, which are matching the policy create above, are now using the Windows Hello for Business Hybrid cloud-trust model (instead of the Windows Hello for Business Hybrid key-trust model).

For Hybrid Azure AD Joined devices

As we have enabled Windows Hello for Business already, as described in this blog, we are just going to put in the settings required to enable cloud trust for Hybrid Azure AD Joined Devices. The first step is to make sure the right ADMX and ADML files are in place in your central policy store in Active Directory. For that copy over the ‘Passport.admx’ and ‘Passport.adml’ shown below over from your Windows 10 or 11 preview build machine (which does support the cloud trust model).

Paste the files into the Central Policy Store in Active Directory within the directories shown below (as we are copying preview build files, I would recommend you to rename the original files first to .old, just in case).

Within the Group Policy Management MMC create a new GPO specifically for cloud trust i.e., ‘IdentityMan Computer Policy – Cloud-Trust’. As the cloud trust setting specifically is a computer setting it’s important that this Group Policy is enabled on an OU containing computers. Applying the Windows Hello for Business Hybrid Cloud Trust model on non-supported cloud-trust operating system won’t break the key-trust experience so we don’t need to configure a separate filter for this matter.

Now the group policy is created let’s edit the Group Policy we just created and enable the new cloud-trust model for hybrid devices as well. Therefore, go to Computer Configuration à Policies à Administrative Templates à Windows Components à Windows Hello for Business. In here go to the setting ‘Use cloud trust for on-premises authentication’ and make sure the setting is set to ‘Enabled’.

The next step is to enablethe setting ‘Use Windows Hello for Business’ which can be set on computer- or user level (please DO NOT check ‘Do not start Windows Hello Provisioning after sign-in’ otherwise the enrollment will never start).

All required configuration steps are now in place for the Hybrid Azure AD Joined Devices as well. On Hybrid Azure AD Joined devices this can be checked as well via the Event Viewer by going to Application and Services Logs –> Microsoft –> Windows –> User Device Registration. In here check the latest events and see if ‘Cloud trust for on-premises auth policy is enabled’ is set to ‘Yes’. If so your device is using the cloud-trust model and you should be good! :-).

Your Hybrid Azure AD Joined devices, which are matching the policy create above, are now using the Windows Hello for Business Hybrid cloud-trust model (instead of the Windows Hello for Business Hybrid key-trust model).

As you can see this setup is much easier to deploy and biggest advantage is that we are not depending on the synchronization of the WHfB public key of the user from Azure AD to Active Directory via Azure AD Connect.


Step 3: End user experience on both devices

The enrollment experience of Windows Hello for Business for end users does not change and will stay the same. What however will change for end users is that they don’t have to wait anymore for the Azure AD Connect synchronization to occur to access on-premises resources (this as the synchronization dependency has been removed). Users can therefore access on-premises resources directly after the Window Hello for Business enrollment process i.e., access an on-premises file share.

Once you’ve accessed the on-premises file share you can also see that you’ve received a Kerberos ticket from a command prompt window by executing the command ‘klist’. As you can see below it shows that a Kerberos ticket has been issued for Johny Bravo and the server which has been accessed is IM-DC01 based on CIFS.


Conclusion

By using the Cloud-Trust deployment model, as explained above, we simplify our Windows Hello for Business hybrid deployment by making sure there are less dependencies and less complexity in the setup. This whereby, even more important, there is no delay in key synchronization for your end users, which therefore improves the Windows Hello for Business hybrid experience as users can work instantly with these credentials in both cloud and on-premises environments!

Besides if you are using FIDO2 Security keys, you got one simple hybrid trust model for both Windows Hello for Business and your FIDO2 Security Keys. This as it’s using the same technology on the background.

It’s time to prepare your environment today for this epic functionality so that once your devices have the latest Windows 10 / 11 build (with the latest updates installed) they are switched automatically to this Windows Hello for Business Cloud Trust deployment model.


Tips & Tricks

As the environment which I’ve used is my blog is a greenfield environment it’s quite easy to describe and build a successful WHfB Hybrid environment based on cloud trust. In practice I’ve seen several misconfigurations which resulted in a non-working Windows Hello for Business Hybrid environment. In some cases it even brought my some headaches so let me at least save you from them and explain the tips & tricks below to you :-).

I’ve verified my whole setup but for some user accounts the key-trust setup isn’t working.

This is probably caused by the fact that users are being a member of specific Built-In Active Directory group which provides administrative premissions. In my lab environment for some simple testing purposes I’ve made the account a member of the ‘Domain Admins’ group which did break the WHfB Cloud-Trust experience. This is cause by the fact that credentials can’t be verified by the Azure ADKerberos Computer object in your Active Directory. You can check this out yourself by going to the ‘Password Replication Policy’ tab, in here you will see that this is only set to allowed for ‘Domain Users’.

This simply implactes the AzureADKerberos object isn’t able to convert the partial TGT to a fully formed TGT.

Verify Samaccountname value in Azure AD.

I hear you thinking, what is the samaccountname value still synchronized to the Azure AD? Yes it is, it however is called ‘Onpremissessamaccountname’ and can be explored via the Graph API. Please make sure that this value is the same as the samaccountname value in Active Directory.

To check this value in the Graph API run the following command:

https://graph.microsoft.com/v1.0/users/johny.bravo@identity-man.eu?$select=onPremisesSamAccountName

The output should be similar to the screen below and tells you the samaccountname in Azure AD:

And as you can see this value is the same as in the Active Directory:

If this is different then you did something unsupported :-)… please check the synchronization rules in Azure AD Connect and make sure these are configured to the defaults… If you never have done something with the synchronization rules editor before, please ask some professional help because this defines everything which is synchronized to the Azure AD. One mistake can break your whole configuration and has immediate user impact.

If the Windows Hello for Business Hybrid Cloud-Trust deployment doesn’t work, make sure the Domain controllers have the required patch installed.

If you have Windows Server 2016 Domain Controllers check if the patch KB4534307 is installed. If you have Windows Server 2019 Domain Controllers check if the patch KB4534321 is installed.

Verify if your subnet belongs to a site within AD Sites and Services where a Server 2016 Domain Controller is available.

It’s important to make sure your clients belongs to a specific site within Active Directory Sites and Services which has a Server 2016 Domain Controller available. You can do this by specifying a subnet within Active Directory sites and services.

First check the IP range which you’re using on your machine, in this case this is 10.31.96.0/24.

Please define this subnet within AD Sites and Services and make sure the subnet belongs to a site containing a Server 2016 Domain Controller.

NOTE: if you have more sites and not all sites have Server 2016 domain controllers this becomes extremely important. If you just have one site the above isn’t required.

If the WHfB enrollment does not start for cloud-trust devices check the Group Policy Settings

When you’ve enabled Windows Hello for Business on Hybrid Azure AD Joined device, which is enabled for cloud-trust, and the enrollment doesn’t start this is due to the fact you are hitting a bug in a specific build. Please make sure to upgrade your Windows 10 21H2 / Windows 11 21H2 device to the latest build.

My Hybrid Azure AD Joined devices which do not support Windows Hello for Business cloud-trust have a ‘broken’ Windows Hello for Business Hybrid key-trust experience.

This is because you are hitting a bug in the patch level of your domain controllers and is not related to the cloud-trust setting being applied. This issue is applicable for:

  • Windows Server 2016; Builds 14393.3930 to 14393.4048.
  • Windows Server 2019; Builds 17763.1457 to 17763.1613.

During the user logon the Windows Hello for Business public key is deleted within Active Directory. Subsequent sign-ins will fail until the user’s public key is written back to Active Directory during the next Azure AD Connect synchronization cycle. This public key will however be deleted again at the next user logon. To resolve this issue please update the patch level of your domain controllers to the latest build which has a fix for the above-mentioned issue.

After switching from key (or cert) trust to cloud trust on Hybrid Azure AD Joined devices my WHfB credentials seem not to be accepted anymore.

If you get pushed the new policy on Hybrid Azure AD Joined Devices to start using cloud trust your first unlock will need Domain Controller connectivity (either via your local network or via VPN). Normally this should not impact you as you do need Domain Controller Connectivity to receive the new policy as well.


I hope you enjoined reading this blog and are now ready and prepared to change your Windows Hello for Business Hybrid model from key-trust to cloud-trust. In my next blog as a follow-up on the password-less series I will explain to you how you can make use of a password-less enrolment via a temporary access pass for your end users (literally sign-in without a password), so stay tuned for more password-less love!

Other related password-less blogs:

29 thoughts on “Improving your Windows Hello for Business Hybrid Password less setup by using Cloud Trust

  1. accidentalsysadmin says:

    Do all DC’s need to be at least Server 2016 for this to work? Or will one compatible DC (2016/2019/2022) per AD site suffice?

    I’m currently untangling some Server 2012R2 DC’s which host other critical services (don’t ask), and want to spin up some new Server 2019 servers to utilize this functionality as a ‘quick win’.

    Great article!

    Like

    1. Pim Jacobs says:

      Yes, totally correct, but as WHfB is an AD Premium P1 feature (and not Intune although it’s positioned in Endpoint Manager), I wanted to show everyone ADMX is an option as well :-).

      Like

  2. Tom says:

    Hi , i’ve done all the pre-reqs (Get-AzureADKerberosServer returns all good info) , i’ve applied the configuration with the oma-uri it seems to be applied, but My devices keeps saying “Cloud trust for on premise auth policy is enabled: No ” , any tips on troubleshooting ?

    It’s a AAD Joined device

    Like

    1. Pim Jacobs says:

      Have you checked if you’ve configured the correct tenant ID in the OMA-URI? I’ve lately seen the same, cloud-trust works but event log keeps saying cloud-trust ‘No’. This was related to the tenant-id not being configured correctly in the OMA-URI setting.

      Like

  3. Henrik Skovgaard says:

    Great article, thanks! It works without issues on newly created users, but for some users in the org that aldready had WHFB setup (without cloud trust), they are still not getting a kerberos ticket when accessing onprem fileshares. Tried to clear msDS-KeyCredentialLink attribute also. Thoughts on this?

    Like

    1. Pim Jacobs says:

      Hi Henrik,

      Do you perhaps know how these users did setup WHFB? Because if they did via cert-trust ‘under the hood’ you can’t easily move to the cloud-trust model (only key-trust does), what you can try is to clean the WHFB container for one user to see if that resolves your issue with this command:

      certutil.exe -DeleteHelloContainer.

      If you logoff and logon the WHFB enrollment should trigger again and you are able to test the hybrid deployment. If this resolves the issue I would strongly recommend to check what you had deployed before as deployment method (cert trust vs. key trust).

      Like

  4. Tim says:

    For some reason I’m receiving a Set-AzureADKerberosServer : Failed to create Azure AD Kerberos Server: Failed to set password for account: LDAP://FQDNdomain.com/CN=AzureADKerberos,OU=Domain Controllers,DC=domain,DC=com

    Like

  5. Jason Schuff says:

    This is a great write-up. I have configured everything as above but I cannot get the PIN to work. It enrolls but once you try to use it you get this is unavailable at this time. I have combed through everything and unable to find why it everything looks right in the event logs and powershell commands and enrollment. But afterwards the actual authentication fails when using the pin.

    Like

    1. Pim Jacobs says:

      Are all domain controllers on 2016 or higher and patched correctly? If you got some 2012 DCs that’s not a problem but that requires you to have AD Sites and Services setup correctly (your client should belong to a subnet which is assigned to a site which contains a DC which is supported). If that’s not the case that could be one of the explanations of the above behaviour.

      Like

  6. Jason R says:

    When trying to run this script from the AD connect server I get the following error:
    Import-Module : Could not load file or assembly ‘file:///C:\Program Files\Microsoft Azure AD
    Sync\Bin\Microsoft.Online.PasswordSynchronization.dll’ or one of its dependencies. The system cannot find the file
    specified

    I checked and there is no “bin” folder under “microsoft azure ad connect”, just an empty Data folder. It appears that the azureadkerberos.psd1 file is calling dll’s in “microsoft azure ad sync”, which is believe was the name for older versions of AD Connect? I am on the latest build of AD connect.

    Like

    1. Pim Jacobs says:

      There shouldn’t be a bin folder beneath ‘Microsoft Azure AD Connect’ as the bin folder resides beneath ‘Microsoft Azure AD Sync’. (I know it’s confusing but not all has been renamed beneath Program Files. Can you please check again if the bin folder is available within the ‘Microsoft Azure AD Sync’ folder. I’m running the latest version as well and for me it’s there and working perfectly fine!

      Like

  7. durrante says:

    Hi there,

    Fantastic blog, question, if users are already setup for Windows Hello, if I enable cloud trust, will they need to reprovision Windows Hello or will it “just work”?

    Thanks!

    Like

    1. Pim Jacobs says:

      After your devices supports the Cloud-Trust settings it will automatically move over. Only if you’re using Hybrid Azure AD Joined devices it requires a line of sight with the domain controller at the moment of policy retrieval.

      Like

  8. durrante says:

    Hi there,

    Fantastic post :), if users are already setup their devices for Whfb and we enable cloud trust, will a end-user reconfiguration be required or will it “just work”?

    Thanks!

    Like

  9. Derek says:

    I just wanted to say a big thank you for the troubleshooting information regarding Password Replication. Turns out my user was in one of the denied groups. That saved my bacon!

    Like

  10. David says:

    Hey there,

    first of all lovely blog here – thank you so much for your work!

    I did the whole setup with the offical microsoft docs and then saw your blog post.

    I still dont’ know what I am missing. Can anyone please help me?

    He are the facts:

    1. We are using Azure join devices only (therefore Windows Hello config policy via Intune).
    2. We didn’t use the any method for Windows Hello towards on prem before (so no migration from key method is needed).
    3. My eventviewer says YES to ‘Cloud trust for on-premises auth policy is enabled’ and no tested to Cloud-TGT.

    Looks like everything is working.

    But everytime I want to access an on prem ressource I get the prompt for Windows Hello fingerprint and when I use it I am not allowed to access the ressource.

    4. I also checked the point with the Password Replication Policy cause in fact my users is also on prem global admin . So I removed my User from global admin group and it still not working.

    Any ideas please?

    Thank you in advance!

    Like

Leave a Reply to Henrik Skovgaard Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s