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

Posted on by Pim Jacobs Posted in IdentityTagged , , , , , , , , , , , , , , , , ,

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 ‘Settings catalog’ and hit ‘Create’.

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

In the configuration settings screen hit ‘Add settings’ and search for the setting ‘Use Cloud Trust For On Prem Auth‘ under Windows Hello for Business and make sure the setting is added and set to ‘Enabled‘. Once ready, verify the settings and hit ‘Next’ twice.

NOTE: Previously there was a need to configure your tenant ID, this isn’t required anymore with the use of this setting.

Now 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 to the ‘Review + Create’ page, 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 cloud-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 caused by the fact that credentials can’t be verified by the AzureADKerberos 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 implies 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:

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

  2. Pingback: Windows Hello for Business – Jacques Dalbera's IT world
  3. Reply
    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. accidentalsysadmin says:

        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!

        Like

      2. Pim Jacobs says:

        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! 🙂

        Like

    1. Reply
      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

  5. Reply
    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

    2. Reply
      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

  7. Reply
    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. Reply
      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

  8. Reply
    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

      2. Pim Jacobs says:

        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).

        Like

  9. Reply
    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. Reply
      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

  10. Reply
    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. Reply
      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

  11. Pingback: World Password Day - Eric on Identity
  12. Reply
    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. Reply
      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

  13. Reply
    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

  14. Reply
    Rasmus Teglgaard says:

    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?

    Like

  15. Reply
    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

  16. Reply
    Jann Kjeldsen says:

    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?

    Like

    1. Reply
      Pim Jacobs says:

      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 :-(.

      Like

  17. Reply
    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

    2. Reply
      Jay R says:

      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.

      Like

      1. Pim Jacobs says:

        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 :-)!

        Like

  18. Reply
    Michele says:

    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?

    Like

    1. Reply
      Pim Jacobs says:

      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?

      Like

  19. Reply
    Jeroen says:

    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

    Like

    1. Reply
      Pim Jacobs says:

      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 :-).

      Like

  20. Reply
    DC says:

    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?

    Like

    1. Reply
      Pim Jacobs says:

      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 🙂

      Like

  21. Reply
    Andrew says:

    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.

    Like

  22. Reply
    A says:

    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?

    Like

  23. Reply
    jan says:

    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?

    Like

  25. Reply
    Bram says:

    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.

    Like

    1. Reply
      Pim Jacobs says:

      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 :-).

      Like

  26. Reply
    jslooten says:

    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

    Like

    1. Reply
      Pim Jacobs says:

      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!

      Like

  28. Reply
    Darren says:

    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

    Like

    1. Reply
      Pim Jacobs says:

      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).

      Like

  29. Reply
    Rain says:

    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

    Like

    1. Reply
      Pim Jacobs says:

      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.

      Like

  30. Reply
    banhchungbanhtet says:

    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

    Like

    1. Reply
      Pim Jacobs says:

      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.

      Like

  31. Reply
    Winston says:

    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.

    Like

    1. Reply
      Pim Jacobs says:

      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.

      Like

  32. Reply
    sahayanadar says:

    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

    Like

    1. Reply
      Pim Jacobs says:

      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.

      Like

  33. Reply
    Techster says:

    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 ?

    Like

    1. Reply
      Pim Jacobs says:

      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.

      Like

  34. Reply
    BaF says:

    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.

    Like

  35. Reply
    N says:

    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?

    Like

  36. Reply
    alex says:

    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?

    Like

    1. Reply
      Pim Jacobs says:

      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.

      Like

  37. Reply
    Peter says:

    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

    Like

    1. Reply
      Pim Jacobs says:

      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.

      Like

  38. Reply
    Peer Scholz says:

    Hi Pim!

    does this work for you with the alternate UPN activated? Meaning, our synced AD-Users have a different local AD UPN than their E-Mail-Adress. In this scenario i get “IsUserAzureAD : NO”

    Like

  39. Reply
    Matthias says:

    Hi Pim,

    we would like to migrate from Whfb key trust to cloud trust. Will the creation of the new computer- and user-object have an impact/influency on the existing AZUREADSSOACC computer and krbtgt user object? I only want to be sure before implementing. I did not find any answer to it, maybe because there is no dependency between these objects.

    Also the answer to the question from Bram would be of interest for me:

    “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?”

    Like

    1. Reply
      Pim Jacobs says:

      Hi Matthias,

      There won’t be any impact on the the AZUREADSSOACC object has that’s used for SSO against cloud resources (on-prem to cloud), not the other way around (cloud to on-prem).

      Related to the RODC question, yes that’s today an unsupported scenario. It however does work when you enable password replication for users on these RODCs. However please be aware you’re going to walk into an unsupported path from a Microsoft perspective (so wouldn’t be my recommendation, I would replace the RODCs or centralize them if you don’t trust the location with a writeable domain controller).

      Like

  40. Reply
    Farook says:

    Hi

    I have couple of questions

    1. My environment have 2 DC’s (both are 2019 ) and Hybrid Azure AD joined machines .
    I enabled WHFB via GPO. Do I need to enable WHFB via Intune also ?

    2. Executed the PS script and confirmed that the AzureADKerbrous object created and also I checked that event ID 358 and confirmed that Cloud trust is enabled “Yes”.

    But WHFB provisioning will not be launched after the signing .Could you please help me to resolve this issue ? When I checked manfully in Sign in option , PIN setup button is greyed out please advise.

    Like

    1. Reply
      Pim Jacobs says:

      Hi Farook,

      Just enabling Windows Hello for Business on-premises won’t help, you need to enable the Windows Hello for business policy from the Intune portal as well. This as your device (I assume it’s a Hybrid Entra Joined device) will be enabled for Windows Hello by GPO but will receive it’s policy settings from Microsoft Entra/Intune. I hope that helps you with your issue.

      Like

  41. Reply
    dulkarfarook says:

    Hi Pim,

    My environment is HAADJ devices and pushed the WHFB policy via GPO. After that I executed the status command. But it shows that “PreReqResult : WillNotProvision” and
    and CloudTGT : NO

    Also it generated Event ID 360.

    My didn’t get the WHFB provisioning window when I enter the windows credentials

    I created AzureADKerbros object and apply the
    +———————————————————————-+
    | Ngc Prerequisite Check |
    +———————————————————————-+

    IsDeviceJoined : YES
    IsUserAzureAD : YES
    PolicyEnabled : YES
    PostLogonEnabled : YES
    DeviceEligible : YES
    SessionIsNotRemote : YES
    CertEnrollment : none
    CloudTGT : NO
    PreReqResult : WillNotProvision

    Like

  43. Reply
    Graham says:

    Hi Pim,

    Great article, this is exactly what I was looking for. We were looking at cloud PKI/radius as a service, but it is very expensive currently.

    I was wondering if there is any risk associated with setting this up as a test.

    Am i right in thinking that it will only affect devices that I push the policy out to?

    If anyone else has already configured Hello it won’t make any changes?

    Also, would publishing the Kerberos key make any changes to devices not using hello or change any authentication settings for us in Azure?

    As I would be rolling this out in our live environment, I am slightly hesitant having not done it before and don’t want to cause issues for our users.

    Hopefully you can assist with these questions.

    Thank you in advance.

    Graham

    Like

    1. Reply
      Pim Jacobs says:

      Hi Graham, The cloud trust policy can easily be scoped to only the device you want to target. Also Windows Hello can be targeted individually via separate policies in Intune or Active Directory by GPO. That will provide you to option to easily test and if that’s the case migrate from key-trust to cloud-trust.

      If you currently did setup certificate trust you do need to delete the hello container as a migration to cloud-trust requires this.

      Hope this helps and answers your questions?

      Like

Leave a comment