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

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

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

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

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

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

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

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

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

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

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

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


Windows Hello for Business Hybrid Cloud-Trust Deployment

Step 1: Creating the AzureADKerberos computer object

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

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

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

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

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

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

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

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -	DomainCredential $domainCred -RotateServerKey -Force

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

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

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

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

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

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

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

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

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

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

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


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

For Azure AD Joined devices

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

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

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

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

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

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

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

Verify the settings and hit ‘Next’.

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

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

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

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

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

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

For Hybrid Azure AD Joined devices

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

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

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

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

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

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

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

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


Step 3: End user experience on both devices

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

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


Conclusion

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

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

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


Tips & Tricks

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

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

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

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

Verify Samaccountname value in Azure AD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Other related password-less blogs:

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

  1. accidentalsysadmin says:

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

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

    Great article!

    Like

      1. 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. Pim Jacobs says:

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

      Like

  2. Tom says:

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

    It’s a AAD Joined device

    Like

    1. Pim Jacobs says:

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

      Like

  3. Henrik Skovgaard says:

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

    Like

    1. Pim Jacobs says:

      Hi Henrik,

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

      certutil.exe -DeleteHelloContainer.

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

      Like

  4. Tim says:

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

    Like

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

  5. Jason Schuff says:

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

    Like

    1. Pim Jacobs says:

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

      Like

  6. Jason R says:

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

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

    Like

    1. Pim Jacobs says:

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

      Like

  7. durrante says:

    Hi there,

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

    Thanks!

    Like

    1. Pim Jacobs says:

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

      Like

  8. durrante says:

    Hi there,

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

    Thanks!

    Like

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

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

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

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

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

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

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

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

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

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

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

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

Leave a Reply to Pim Jacobs Cancel reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Connecting to %s