8 hours ago8 hr Windows Hello for Business (WHfB) lets people sign in with a PIN or biometric tied to the device's TPM instead of a password. In a hybrid environment, the hard part has always been getting on-premises resources like file shares, printers and Kerberos apps to accept that Hello sign-in. Get it wrong and the user signs in with a PIN, then gets a password prompt the moment they open a share. The older key trust and certificate trust models needed either a PKI with certificates on your domain controllers, or a wait while public keys synced back to AD. Cloud Kerberos Trust removes both. Entra ID issues a partial Kerberos ticket that your DCs trust. It's now Microsoft's recommended model for hybrid deployments, and it's what we deploy. Check these before you start Hybrid joined or Entra joined devices on Windows 10 21H2 or later (fully patched) or Windows 11. Domain controllers running Windows Server 2016 or later, fully patched, at every site where users will authenticate. Entra Connect syncing your users. Intune (or Group Policy) to deploy the WHfB settings. A Domain Admin account in the on-premises domain and a Global Administrator (or Hybrid Identity Administrator) account in Entra ID. Users who can complete MFA, since WHfB provisioning requires it. Why we went with cloud trust There's no PKI involved. You don't have DC certificates to issue and renew for Hello, and you don't have to worry about CRL availability. There's also no key sync delay. With key trust, a new user's public key had to sync to AD before on-premises SSO worked, so the instructions for new staff were basically "set up Hello, then wait up to an hour." With cloud trust it works right after provisioning. And if you plan to use FIDO2 security keys for hybrid sign-in, the same Entra Kerberos object supports that too. Create the Entra Kerberos server object This creates a read-only domain controller-style computer object (AzureADKerberos) in your domain and publishes its key to Entra ID, so your DCs can trust the tickets Entra issues. Run it from an elevated PowerShell session on a domain-joined machine that can reach a writable DC. # TLS 1.2 for the PowerShell Gallery on older systems [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber $domain = $env:USERDNSDOMAIN # e.g. CONTOSO.LOCAL $upn = "admin@contoso.com" # Entra Global Admin or Hybrid Identity Admin $domainCred = Get-Credential # Domain Admin in the on-prem domain Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn -DomainCredential $domainCred # Confirm it exists and the key versions match Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $upn -DomainCredential $domainCred If your admin account requires MFA, the module supports an interactive sign-in instead of passing the UPN. Check the module's help for the current parameters. In AD you should now see an AzureADKerberos computer object in the Domain Controllers OU and a krbtgt_AzureAD user. Don't delete or move either one. Repeat this for each domain in the forest where users sign in. The WHfB policy in Intune Create a Settings catalog profile for Windows and search for Windows Hello for Business. At a minimum, set Use Windows Hello For Business to Enabled (with your PIN complexity and biometric preferences) and Use Cloud Trust For On Prem Auth to Enabled. Under the hood, the cloud trust setting is this CSP. ./Device/Vendor/MSFT/PassportForWork/<TenantID>/Policies/UseCloudTrustForOnPremAuth = true Assign it to a pilot device group. If you already have a tenant-wide WHfB configuration under Windows enrollment settings, make sure the two don't conflict. The settings catalog profile is the one we rely on. Without Intune, the equivalent Group Policy setting is "Use cloud Kerberos trust for on-premises authentication" under the Windows Hello for Business administrative templates. Try it with one user Sync policy on the pilot device and have the user sign out and back in. After MFA, they should be prompted to set up Windows Hello. Then lock the machine and sign in with the PIN. Confirming on-prem SSO works Run these as the user, while signed in with Hello. dsregcmd /status klist cloud_debug klist In dsregcmd /status, under SSO State, you want CloudTgt : YES and OnPremTgt : YES. Under the NGC prerequisite check, NgcSet : YES confirms the user has provisioned Hello. klist cloud_debug should report that the cloud primary (hybrid logon) TGT is available and that cloud Kerberos is enabled by policy. klist should show a krbtgt ticket for your on-premises realm, plus service tickets once you browse a file share. The test I care about most is opening \\fileserver\share while signed in with the PIN. No password prompt means on-premises SSO works. What tripped us up Privileged accounts don't work, and that's by design. The Entra Kerberos object behaves like an RODC, so accounts that can't have their credentials cached on an RODC, such as members of Domain Admins and other groups in the "Denied RODC Password Replication Group," won't get on-premises tickets from cloud trust. They'll sign in to Windows fine and then fail to reach on-premises resources. Admins should be using a separate daily account anyway. If any DC a client might talk to is missing the required updates, sign-ins fail intermittently depending on which DC answers. That's a miserable one to chase, so patch them all before the pilot. Devices previously set up for key trust or certificate trust may keep using it. Clean up old GPOs and policies, and have users reprovision if needed. Kerberos fails if the client and DC clocks drift more than about five minutes apart. Check time sync on remote and VPN devices. Getting the on-premises ticket still needs line of sight to a DC when the resource is accessed. Hello sign-in to Windows works off-network, but file shares still need the VPN. One last thing that's easy to forget once everything works. Rotate the Entra Kerberos server key periodically with Set-AzureADKerberosServer -RotateServerKey (using the same domain and credential parameters), and put it on your maintenance calendar so it doesn't depend on somebody remembering.
Create an account or sign in to comment