The goal: passwordless sign-in with on-premises single sign-on
Windows Hello for Business (WHfB) replaces routine password entry with a device-bound asymmetric key unlocked by a PIN or biometric gesture. Cloud Kerberos trust then lets hybrid users access Kerberos-integrated Active Directory resources without deploying sign-in certificates to users or domain controllers. It does not automatically remove the underlying AD account password: retain a recovery method and protect the password and any remaining password-based workflows.
Consider an employee who unlocks a Microsoft Entra joined PC with a WHfB PIN and opens an on-premises file share over VPN. Microsoft Entra ID issues a partial Kerberos TGT with the primary refresh token; the client contacts a writable domain controller to obtain a complete TGT and service tickets. No DC connectivity means no new on-premises SSO, even where cached Windows sign-in still works.
Cloud trust, key trust and certificate trust compared
No WHfB sign-in PKI does not mean no certificates anywhere. EAP-TLS Wi-Fi or VPN, S/MIME, and apps requiring client certificates may still need a PKI or another certificate delivery method. A configured Use certificate for on-premises authentication policy takes precedence over cloud trust. Do not layer the models blindly.
| Trust model | AD authentication | WHfB certificates | Best fit |
|---|---|---|---|
| Cloud Kerberos trust | Entra partial ticket, complete TGT from DC | No WHfB sign-in certificates | Preferred hybrid route without certificate authentication requirements |
| Key trust | User public key and DC certificate-based authentication | PKI for DCs | Existing estates; migration to cloud trust is possible |
| Certificate trust | User certificate | PKI, user certificates and supporting components | When certificate-based authentication is needed |
Prerequisites and exclusions before the pilot
WHfB cloud trust itself does not require Entra ID P1/P2, but Intune, automatic MDM enrolment and some Conditional Access policies have separate licensing. Assess the whole design instead of advertising a zero-cost rollout.
- Sync AD identities to Microsoft Entra ID, including onPremisesSamAccountName, onPremisesDomainName and onPremisesSecurityIdentifier; identify every domain and forest containing pilot users.
- Use Microsoft Entra joined or hybrid joined devices. Minimum WHfB cloud trust client versions are Windows 10 21H2 with KB5010415 or later, or Windows 11 21H2 with KB5010414 or later; keep devices supported and updated. AD-only joined clients are not supported for this hybrid model.
- Use patched Windows Server 2016/2019 DCs or Windows Server 2022/2025, with enough writable DC capacity at relevant AD sites. If Kerberos encryption types are constrained through policy, enable AES256_HMAC_SHA1.
- Validate Microsoft Entra Connect, DNS, DC reachability and VPN, MFA for provisioning, TPM support for device-bound keys, and a documented recovery path.
- Inventory privileged accounts, RDP/VDI, Run as, smart cards, pre-logon VPN, EAP-TLS and applications that specifically require certificates; test each workflow separately.
Step 1 — Set up Microsoft Entra Kerberos for the right domains
If the organization already uses Microsoft Entra Kerberos for FIDO2 sign-in to on-premises resources, reuse its object. Otherwise, create an AzureADKerberos object for each relevant domain and forest. It looks like an RODC object but is not a physical server. Run the Microsoft module on the Entra Connect server or a host with Microsoft.Online.PasswordSynchronization.Rpc.dll and DC access. The Microsoft procedure requires an AD Domain Admin/Enterprise Admin and an Entra Hybrid Identity Administrator; remove temporary elevation afterwards.
Confirm the returned domain, AD object and Entra publication. Repeat for each domain containing intended users. Do not put administrator passwords in scheduled tasks or configuration files.
# Run on an approved server, after validating the domain and change window.
Install-Module AzureADHybridAuthenticationManagement -Scope CurrentUser
Import-Module AzureADHybridAuthenticationManagement
$domain = 'ad.example.com' # Replace with the user's actual AD domain
$cloudUpn = 'hybrid-admin@example.onmicrosoft.com'
$domainCred = Get-Credential -Message 'Required AD administrator (UPN)'
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUpn -DomainCredential $domainCred
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUpn -DomainCredential $domainCredStep 2 — Roll out an Intune pilot
Create a Windows Settings catalog policy in Intune and assign it to a small, representative pilot group. Under Windows Hello for Business, set Use Windows Hello For Business to true, Use Cloud Trust For On Prem Auth to Enabled, and Require Security Device to true when devices have TPMs. If a suitable tenant-wide WHfB policy is already enabled, Microsoft says you may only need the cloud trust setting. Check per-device policy status and avoid duplicating settings across policy types.
| Settings catalog entry | Pilot value | Purpose |
|---|---|---|
| Use Windows Hello For Business | true | Enable provisioning |
| Use Cloud Trust For On Prem Auth | Enabled | Enable hybrid Kerberos trust |
| Require Security Device | true | Bind keys to TPM; verify device capability |
Group Policy option for hybrid joined AD-managed devices
Update Passport.admx and Passport.adml in the Central Store, then security-filter a pilot GPO. Under Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business, enable Use Windows Hello for Business, Use cloud Kerberos trust for on-premises authentication, and, if appropriate, Use a hardware security device. The WHfB enablement setting also exists under User Configuration, but the cloud trust setting is computer-only. Where both scopes define WHfB enablement, the user policy wins for that setting.
Group Policy takes precedence over conflicting Intune WHfB settings per Microsoft's deployment guide. Assign clear policy ownership; do not enable Use certificate for on-premises authentication on these devices, because it takes precedence over cloud trust.
gpupdate /force
gpresult /h C:\Temp\whfb-gpo.html # Create C:\Temp first
dsregcmd /statusStep 3 — Provision users and validate real access
After an eligible sign-in, the user completes MFA, creates a PIN and optionally registers biometrics. The key pair is bound to the device, preferably its TPM. On a hybrid joined device, the first PIN sign-in requires line of sight to a DC. For remote workers, test pre-logon VPN or perform that first sign-in on the corporate network. Next test cached unlock offline, then on-premises access after VPN and DC connectivity are restored.
OnPremTgt=YES shows a cloud Kerberos ticket for on-premises resources, not proof that every app is accessible. Diagnostic field names vary by Windows version. Test an actual resource by DNS name and review both tickets and permissions. User Device Registration/Admin helps explain provisioning failures. Avoid pasting full dsregcmd output into public tickets because it contains tenant and user identifiers.
dsregcmd /status
# Review AzureAdJoined, DomainJoined, AzureAdPrt, NgcSet, OnPremTgt where available.
klist
# Open \\server.ad.example.com\share, then rerun klist for a service ticket.Privileged accounts: preserve the RODC boundary
The AzureADKerberos object enforces restrictions similar to an RODC. Direct or indirect members of built-in privileged groups generally cannot use cloud trust to access on-premises AD resources. This protects the boundary between Entra and AD. Microsoft explicitly advises against relaxing the Password Replication Policy on CN=AzureADKerberos to allow such accounts.
- Pilot a standard user account for business resources; handle administrators separately.
- Keep distinct admin identities, dedicated admin workstations and a documented recovery method.
- Do not weaken protected group membership or RODC replication policy merely to make a WHfB test pass.
Prove each application path rather than assuming support
Microsoft's FIDO2 security-key guidance lists unsupported RDP, VDI, Citrix and Run as scenarios with security keys; that does not establish identical support rules for all WHfB workflows. Test each method, client and application. Connecting to a share by IP rather than FQDN can change the authentication path.
| Scenario | Pilot validation |
|---|---|
| SMB shares and Kerberos intranet | PIN, VPN, FQDN, klist, effective access and permissions |
| Off-site sign-in | First hybrid sign-in with DC, then cached unlock and VPN reconnection |
| RDP, VDI, Citrix | Test the exact sign-in method and client; do not extrapolate FIDO2 key limitations to every WHfB workflow |
| EAP-TLS Wi-Fi/VPN, S/MIME | Validate the separate certificate deployment mechanism |
| Legacy NTLM apps or Run as | Validate exact workflows, keep fallback and plan modernization |
Troubleshoot the right layer before changing policy
- No WHfB prompt: check device join, Intune/GPO scope, TPM, provisioning MFA and User Device Registration/Admin.
- PIN works but file share does not: check the Kerberos object for the user's domain, synchronized attributes, OnPremTgt, DNS, VPN, clock and writable DC.
- Only privileged accounts fail: inspect protected groups and RODC restrictions; do not relax replication policy.
- Cloud trust ignored: look for an existing certificate trust policy or conflicting GPO/Intune settings.
- First hybrid PIN sign-in fails remotely: retry with DC line of sight before blaming the TPM.
dsregcmd /status
klist
gpresult /r
Get-WinEvent -LogName 'Microsoft-Windows-User Device Registration/Admin' -MaxEvents 20 | Select-Object TimeCreated,Id,MessageDeployment rings, rollback and success criteria
Start with a handful of Entra joined and hybrid joined PCs spanning real apps, locations and VPN configurations. Track provisioning, Windows sign-in, file shares and intranet access, real certificate needs, support contacts and resolution time per ring. Expand only after critical workflows pass. Keep an existing, controlled sign-in fallback during the transition and prepare users and support staff.
A migration from key trust is documented. Certificate trust has no direct in-place migration: Microsoft requires redeploying WHfB after deleting the Hello container in the user's context. Treat that destructive operation as a separate tested project, with a safe access route. Success means sustained access without a return to routine password prompts or weakened privileged account protections—not merely a high number of PINs enrolled.
- Preparation: validate synchronization, DCs and network; create or verify the Kerberos object in a change window.
- Pilot: assign either Intune or GPO to a small group; provision WHfB and test on-site, off-site and after VPN reconnection.
- Expansion: add groups in waves; track app and ticket failures; deal with privileged identities and certificates separately.
- Rollback: unassign or disable the targeted WHfB policy, retain existing sign-in and recovery; do not delete Hello containers or Kerberos objects without assessing FIDO2 dependencies and planning a separate migration.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →