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-trust | Key-Trust | Certificate-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 TPM | Windows 10 & 11 devices |
| Synchronized Identities via Azure AD Connect | Synchronized Identities via Azure AD Connect | Synchronized 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 site | Windows Server 2008 R2 domain controllers |
| Windows Server 2008 R2 domain and forest functional level | Primary Domain Controller role hosted on a Server 2016 Domain Controller | Windows 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 level | Windows Server 2008 R2 domain and forest functional level |
| Certificate Authority based on Server 2012 or higher | Certificate Authority based on Server 2012 or higher | |
| Certificate Revocation List internally accessible | New KDC certificate deployed to Domain Controllers | |
| New KDC certificate deployed to Domain Controllers | New WHFB certificate deployed to end user devices | |
| Root & Intermediate certificates deployed to clients | Root & 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.
- User signs in to their Windows 10 or 11 device with their Windows Hello for Business credentials and authenticates to Azure AD.
- 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.
- The TGT is returned to the client along with their Azure AD Primary Refresh Token (PRT).
- The client machine contacts an on-premises AD domain controller and trades the partial TGT for a fully formed TGT.
- 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.
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:
- Introduction to a password-less era
- Password-less 1 of 5: Going password-less with phone sign-in
- Password-less 2 of 5: Going password-less with Windows Hello for Business
- Password-less 3 of 5: Going password-less with Windows Hello for Business Hybrid
- Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 1
- Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 2
- Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 1
- Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 2
- Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 3
- Password-less continued: Upgrading your password-less experience with Windows Hello for Business Hybrid cloud-trust.
- Password-less continued: Using the Passwordless Phone Sign-in experience for multiple accounts on iOS!
- Password-less continued: Using a Temporary Access Pass for Bootstrapping your Passwordless Journey
Identity Man 
Great post, really helped me to understand the deployment better!
LikeLike
Thanks!
LikeLike
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!
LikeLike
Yes at least one per AD Site, but keep in mind that if you’ve got a big user base I would encourage you to look at the deployment for windows hello for business hybrid here: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers
This is reffered to as key trust, but per my understanding you can use the same for cloud trust!
Hope that helps :-)!
LikeLike
Hi Pim,
I’ve managed to get this configured for my environment now. However, whenever I try logging on it comes up with ‘this option is currently unavailable’ for WHFB authentication methods (PIN/Biometrics).
I can see the ‘Windows Hello for Business’ authentication method succeeded along with the key registering against Azure AD – but it doesn’t progress past the logon screen.
The site I’m querying has two Server 2012R2’s and a single Server 2019 DC. Kerberos server is installed on the Server 2019 environment.
Any help/guidance would be much appreciated.
Thanks!
LikeLike
Did you check the account you’re using isn’t part of an administrative group (like domain admins?) and did you patch the server 2019 DC with the latest patches? Furthermore I’ve seen a lot of people just copying the OMA-URI and not using there own tenant-ID.
Hope this is going to help you out! 🙂
LikeLike
If you do a brand new deployment, you can skip the ADMX part, and configure everything in Intune, it will apply to Hybride device as well
LikeLike
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 :-).
LikeLike
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
LikeLike
Are you sure you did configure the OMA-URI correctly (including your tenantID)?
LikeLike
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.
LikeLike
Do you know if this is working with RDP authentication to on-prem servers?
Btw, long time no see 🙂
LikeLike
Hi Magnus,
No for RDP you need to run some extra configuration, this is the same as was there for key-trust. More details about this can be found here on the docs:
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs
Hope this helps and you’re doing great of course! :-).
Pim
LikeLike
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?
LikeLike
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).
LikeLike
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
LikeLike
Just to check, are you running the cmdlet as a Domain Admin within this domain?
LikeLike
I have this same error and am running as a DA.
LikeLike
Does the domain exist of a root and child domain? If this is the case I would recommend to use an account with Enterprise Admin Privileges as with that privileges you can manage the forest (root and child).
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
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!
LikeLike
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!
LikeLike
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.
LikeLike
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!
LikeLike
Great post. One question though: Dual Enrollment was earlier only support for cert trust deployments – not for key trusts. Do you know if Dual Enrollment is supported with Cloud Trust?
LikeLike
Hi Rasmus,
As far as I’m aware Dual Enrollment is not supported as well with cloud trust.
LikeLike
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!
LikeLike
Thanks and you’re welcome! 🙂
LikeLike
Hi Great posts. Your here to make my life a whole lot easier, i like it 😉 With that being said. We have a scenario where we have alot of different 365 tenants but only one local domain. My question is will this work for that type of scenario?
LikeLike
Hi Jann,
Thanks that’s where I blog for haha! Good question, the problem with Single AD multi-tenant here is the same as with PHS + Seamles SSO, the object name created in on-prem AD is a single object which contains keys. So for your first setup this will work great, the second one however will start to work but will break the first setup as the keys are changed on the object. So coming back to your question, it will work but only for one single tenant, not for others.
Probably not what you hoped for but it’s simply not available today :-(.
LikeLike
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!
LikeLike
After removing the user from the on-prem groups did you signed off and signed in? As that’s mandatory (just checking) 🙂
LikeLike
oh my gosh….
It was really that simple.
Thank you man LUL !
LikeLike
What are the security implications of removing some of the protected groups from the RODC object so say, domain admins can use FIDO for sign-in? I can’t find any documentation on what the trade-off here would be. On one hand securing the domain admin accounts with Fido augments security (obviously), but obviously removing domain admins from being blocked on the rodc object has some form of security implication that is negative. Question is, is the trade-off worth it? The only other way I see to secure an admin account is with PIV smartcard or some third party product like auth lite.
LikeLike
Hi Jay,
This is a good question! In normal cases an RODC lands on a physical location which you don’t trust and for that reason don’t want to have passwords stored. In this case it’s a virtual object so that argument doesn’t apply in this case / scenario.
Another argument is mainly based around using synchronizing your admin accounts…. I’m not sure what your license type is, but if you gain access to a synchronized admin account within the cloud, that would give you access as well to your on-premises Active Directory because of SSO in this case. So the answer here is what kind of security measurements have you taken to protect these accounts within the cloud (MFA, PIM, IP, CA, etc) and did you deployed Defender for Identity in your on-premises AD to detect anomalies for these accounts and take follow up actions if needed?
I hope the above helps you to determine why this is done by default and if your trade-off is worth it :-)!
LikeLike
Hello and congratulations for the article; I have configured everything as per guide, but it doesn’t seem to work, or rather, it still seems to work as “Key Trust” and not as “Cloud Trust”; what can i check / change?
LikeLike
Hi Michelle,
Have you made sure that:
– You’re running a support OS Version?
– You’ve configured the OMA-URI policy correctly with the correct tenant-id?
– The AzureADKerberos Server object has been created?
LikeLike
Hi great blog!
I have a question.
Do you need to create both policy’s? In Intune and on prem on your local AD?
If you already enable WHFB in intune do you still need to create the cloud trust policy in intune for your hybdrid device or do you need both on prem and in Intune to make it work with hybdrid devices.
Thanks
LikeLike
Hi Jeroen,
It depends which deployment model you have for your devices, if you have AADJ devices just enabling settings from Intune works. If you have Hybrid not managed by Intune you need to do it from on-prem if these devices are managed with Intune you can do it from Intune just like for AADJ devices.
Hope this helps :-).
LikeLike
Hi,
I have three domain controllers – two Server 2012 R2 and one Server 2016 (14393.5066).
Am I still able to implement WHFB hybrid-joined deployment?
If yes, I would like to receive clarification with your statement below.
“The next step is to enable the 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).”
We’re a small company, so if I decide to deploy WHFB, I would like to go to each user individually. So do I check mark ‘Do not start Windows Hello Provisioning after sign-in’ – if I decide to go with this?
LikeLike
Hi,
It depends if these domain controllers are all hosted within the same AD Site within AD Sites and services. If that’s the case it would work, however I would recommend to look at the deployment guide around DCs: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.
The checkbox ‘Do not start Windows Hello provisioning after sign-in’ blocks the enrollment steps, so that’s something you should never enabled, If you want to do it user by user you just need to create a policy on user level for instance and make sure users are one-by-one included in the policy (which can be done in many different ways).
Hope that helps 🙂
LikeLike
Hi – amazingly clear write up thank you.
We’ve gone straight into Cloud-Trust, and it all seemed to go very well. The Kerberos object was created fine, deployed the policy through Intune as we have AzureAD joined device, and the event log came back as Cloud Trust Enabled : Yes. I can also see the KeyCredentialLink is populated for my user in AD, so can assume AzureAD connect is working correctly….. But sadly it does not work.
WHfB is works fine, and we can sign into the device using that, but if we try to access an on-prem resource we get the following: System cannot contact a domain controller to service the authentication request.
However, if we sign into to the laptop with a password, we can access the resource fine. It also works if I sign into the laptop with a password, lock the device, and then unlock with WHfB.
I’ve made sure the subnets are in Sites and Services, and the user was not in any admin group – it was in Organization Management, but still no joy.
All our DCs are 2019 and fully patched.
Love to know your thoughts on this.
LikeLike
Hi Andrew,
Question: Are you by any chance using RODC’s in your environment?
LikeLike
Hello, does my user succesfully logged in with a PIN to the “Azure AD-Domain Joined” machine in order to access file server in on-prem, the user must have permanent access to local DC, yes? in other words, if I take my computer outside of the network where the domain controller is reachable, I will not be able to access file shares resources?
LikeLike
If your DC is reachable and your file server isn’t (i.e. via VPN) yes you cannot access your file share.
If both are accessible (via i.e. VPN) this would work perfectly.
LikeLike
Hi, I tried Configuring cloud trust but I get Event ID 358
with following point set to No:
User certificate for on prem auth policyis enabled: NO
Cloud Trust for on prem auth policy is enabled: NO
User Account has cloud TGT: Not Tested
i cant help myself, do you have an idea?
LikeLike
Hi Jan,
Can you please check you’ve entered the correct Tenant-ID within the OMA-URI policy? If that’s entered wrong Cloud-Trust won’t be enabled.
Hope this helps.
LikeLike
Hi Pim
Yes Tenant-ID is correct.
LikeLike
Can you perhaps send me a printscreen of one of the event logs (containing all details) via LinkedIn?
LikeLike
Hi Pim
I cant send you a Message cause I dont have LinekdIn Premium…
LikeLike
If you connect me on LinkedIn (or twitter) you should be able to message me 🙂
LikeLike
Hi Pim,
Nice article, well explained.
I’m getting ‘NULL SID’ discard messages when attempting to authenticate – the client reporting ‘the service is temporarily unavailable’.
Pretty much the same as the Reddit post here: https://www.reddit.com/r/Intune/comments/vslf5b/windows_hello_for_business_cloud_trust/
Have you seen this before? Estate is mainly 2012R2 with a 2019 DC for WHFB.
Thanks.
LikeLike
Hi John,
Are you sure you’re testing with a non-adm account (no member of domain or enterprise admins or what so ever)?
LikeLike
The MS kb article mentions: “If you’re using the hybrid cloud trust deployment model, you must ensure that you have adequate Windows Server 2016 or later read-write domain controllers in each Active Directory site where users will be authenticating for Windows Hello for Business.”
Is this correct? Half of our sites only have an RODC (2019/2022) so half the company can’t use WHFB then? We do allow password replication for the relevant users per site if that would make a difference.
LikeLike
Hi Bram,
What you can try to do is to allow the AzureADKerberos server object to do caching, that will perhaps allow you to get a referral ticket from an RODC. I’ve tried this myself so I’m not sure of the outcome but would of course be interested to know :-).
LikeLike
Hi Pim,,
Thank you for this guide! We’ve followed your instructions, but somehow it’s not working, can you help us?
Good to know that we:
* We didn’t use any method like key-trust or certificate-trust before. So this is new for us.
* We only have Azure joined devices (therefore Windows Hello For Business is configured via Intune)
* We’ve created the AzureAdKerberosServer through our Windows Server 2019 Domain Controller. When we verify this via the Powershell command you provided, all details are filled except ‘CloudTrustDisplay’ which remains empty.
* The OMA-URI configuration profile in Azure has been succesfully deployed to our test machine, which also has the WHfB Intune policy applied.
* The event viewer of our test machine gives the following output: (Notice that ‘Cloud trust for on-premises auth policy is enabled’ is set to No and ‘User account has Cloud TGT’ is set to Not Tested
Windows Hello for Business provisioning will be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Machine is governed by mobile device management policy.
Cloud trust for on premise auth policy is enabled: No
User account has Cloud TGT: Not Tested
Hope you can help us!
Regards,
J
LikeLike
Hi,
Have you tried doing a dsregcmd /refreshprt on the device itself?
My guess would be that you need to get a new PRT with TGT details inside so the partial TGT ticket is loaded from the Azure AD, whereby the client is able to ‘trade’ that in AD for a fully formed TGT.
PS. You can forget the ‘CloudTrustDisplay’ as that’s doing nothing (check that before public preview with Microsoft already).
Hope the above is helping you out!
LikeLike
Yes, it’s working, thanks!
LikeLike
Hi , great article and just going through this myself. I have noticed the accounts are not working and they are a member of the deny in the password replication policy. Can I remove the group e.g Account Operators or does the account need to be removed from these groups and leave the password replication policy alone ?
Cheers
LikeLike
Best is to leave the replication policy as is for security reasons. Therefore remove the account from the account operators role and create a separate account instead for that purpose (least privilege).
LikeLike
Dear,
I have some problems with deployment. Can Hybrid AAD join the CloudTrust model to work with ADFS? Is there a way to get CloudTrust to work with ADFS? Can you guide me? Or are we required to use Hybrid AAD Join Certificate Trust when we have ADFS? I hope to hear back from you soon. Thank you very much
LikeLike
First of all, I would strongly encourage you to move off AD FS and start using PHS + SSO or PTA. AD FS is way more vulnerable for attacks and less secure than Azure AD Authentication. Then secondly, as far as I know yes you can work with devices using WHfB hybrid cloud-trust and AD FS as long as the authentication method on AD FS called Microsoft Passport Authentication is enabled. I haven’t set that scenario up in a lab environment and as its AD FS which I would personally rather see less than more I’m not planning to write a blog about it (sorry).
In short, the best advice I can give you is to start using staged roll-out https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-staged-rollout to move of AD FS whenever that’s possible.
LikeLike
I have some problems with deployment. Can Hybrid AAD join the CloudTrust model to work with ADFS? Is there a way to get CloudTrust to work with ADFS? Can you guide me? Or are we required to use Hybrid AAD Join Certificate Trust when we have ADFS? I hope to hear back from you soon. Thanks
LikeLike
First of all, I would strongly encourage you to move off AD FS and start using PHS + SSO or PTA. AD FS is way more vulnerable for attacks and less secure than Azure AD Authentication. Then secondly, as far as I know yes you can work with devices using WHfB hybrid cloud-trust and AD FS as long as the authentication method on AD FS called Microsoft Passport Authentication is enabled. I haven’t set that scenario up in a lab environment and as its AD FS which I would personally rather see less than more I’m not planning to write a blog about it (sorry).
In short, the best advice I can give you is to start using staged roll-out https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-staged-rollout to move of AD FS whenever that’s possible.
LikeLike
Hi Pim,
I have followed as mentioned in the article.
I used Intune.
The machines are Hybrid Azure Joined.
No previous set up of Key trust or Certificate trust. Tenant Id verfied in Oma-URI.
We’ve created the AzureAdKerberosServer through our Windows Server 2016 Domain Controller.
The windows 10 machine is in line of sight to the DC
Windows Hello for Business provisioning will be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: No
Machine is governed by none policy.
Cloud trust for on premise auth policy is enabled: Yes
User account has Cloud TGT: Yes
we are able to set up PIN.
But when we try to login with PIN, it errors out saying :
“Your credentials could not be verified”
“something went wrong and your PIN isn’t available (Status :0xc00000bb substatus 0x0)
Hope you can help us.
LikeLike
In this example I would first recommend you to clear your Windows Hello for Business container with the cmdlet:
certutil.exe -DeleteHelloContainer
Then sign-off and on again and re-enroll for Windows hello for Busines.
LikeLike
We have almost done it, but still not able to login using PIN
We didn’t use key-trust or certificate-trust before.
We have Hybrid Azure joined devices- Configured via Intune
We’ve created the AzureAdKerberosServer through our Windows Server 2016 Domain Controller.
The OMA-URI configuration is verfied, tenant id is correctly entered.
====
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Machine is governed by mobile device management policy.
Cloud trust for on premise auth policy is enabled: Yes
User account has Cloud TGT: Yes
We are able to set up PIN, but while logging in with PIN we get error
Something went wrong and you PIN isn’t available (status: 0xc00000bb, substatus: 0x0). Click to setup your PIN again
Could you please guide us on this
LikeLike
In this example I would recommend you to clear your Windows Hello for Business container with the cmdlet:
certutil.exe -DeleteHelloContainer
Then sign-off and on again and re-enroll for Windows hello for Busines.
LikeLike
Has anyone got this working with authenticating against SQL Servers ? It works when accessing shares but when trying to connect to a SQL server it doesn’t, when logging on with username/password it does authenticate towards the SQL server ?
LikeLike
I’ve haven’t tried this to SQL Servers, so to be honest I’m not sure, my lab also doesn’t contain an SQL server based on that and the information you provided that it does work for shares but not SQL I think that confirms that you can’t use WHfB hybrid there.
LikeLike
Hi,
just want to leave this here for anybody with issues.
We got the following logs and it doesn’t work:
(User Device Registration Log, Event 362 and 360)
360:
Cloud trust for on premise auth policy is enabled: No
User account has Cloud TGT: Not Tested
362:
User certificate for on premise auth policy is enabled: Yes <–HINT!
Enterprise user logon certificate enrollment endpoint is ready: Not Tested
User has successfully authenticated to the enterprise STS: No
And (dsregcmd /status)
IsDeviceJoined : YES
IsUserAzureAD : YES
PolicyEnabled : YES
PostLogonEnabled : YES
DeviceEligible : YES
SessionIsNotRemote : YES
CertEnrollment : enrollment authority
AdfsRefreshToken : NO
AdfsRaIsReady : NO
LogonCertTemplateReady : UNKNOWN
PreReqResult : WillNotProvision
And (HelloForBusiness Log, Event 7211, 7206, 7054)
We searched for hours until we noticed "User certificate for on premise auth policy is enabled: Yes" but we couldn´t find any policy in our domain for this.
All our Policies regarding Hello for Business has been set at the computer level.
However we found the following registry key
Registry Hive HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER
Registry Path SOFTWARE\Policies\Microsoft\PassportForWork
Value Name UseCertificateForOnPremAuth
This Value was set to 1 at the User level on two different computers, so maybe it´s default somehow.
We created a new user policy with the setting "Use certificate for on-premises authentication" as disabled.
After gpupdate the registry value changed to 0.
We logged off and on again, Windows Hello starts without any issues.
LikeLike
Can users still be able to login with a password with this setup? Also I am trying to setup for Azure Hybrid Join devices, would you please be able to provide me a full article with the all information, I don’t have to go back and forth to check information I need?
LikeLike
Yes, users would still be able to login with a password with this setup, this as we only ‘enable’ additional credential providers within Windows and don’t remove any.
LikeLike
How does user password changes work for hybrid cloud trust setup. so lets say i am a user and my domain password just expired while at home and i need to change it. Will WH4B carry on working, ie pin, face id or will i need to connect to a VPN to re-set pin etc?
LikeLike
Hi Alex,
Yes Windows Hello for Business will stay working for cloud resources, however for on-premises resources you won’t get a prompt and you will be denied access. They only solution is to set password to ‘never expire’ and increase the complexity a bit so you’re protected from brute force attacks.
Ideally you would go fully Passwordless and scramble the password (like what I did for my own account), but that requires you to have the app modernization finished.
Hope this helps.
LikeLike
i follow the step, the user now can use full username login and passwordless to login On-premises server , but user cannot use existing login such as Hello and PIN ) to assess
LikeLike
Hi Peter,
Not sure if I understand you correctly, you can use passwordless logins to on-premises servers but not with existing logins? Are you referring to the fact that new enrollments work but existing enrollments break? If so I would suggest to ‘reset’ the windows hello container on existing devices wit the cmdlet: ‘certutil.exe -DeleteHelloContainer’.
Be aware that this requires end-user to re-enroll, hope this helps you out (but not sure if I interpreted your question correctly.
LikeLike