🚨 What Is Happening & Why It Matters
Windows Hello for Business (WHfB) with Cloud Kerberos Trust is the modern passwordless deployment model for hybrid enterprises. It lets users sign in with PIN, fingerprint, or face recognition and still access on-premises file shares, printers, and legacy services — without passwords, certificates, or on-prem PKI. Yet in 30–50% of hybrid deployments, the rollout fails silently.
The failure is never one thing. Cloud Kerberos Trust is a four-layer orchestration where on-premises AD, Entra ID, Intune, and the device itself must all be precisely configured in sequence. Miss one step, apply one policy to the wrong scope, or leave one legacy GPO in place — and users cannot enroll. No error. No alert. Just non-compliance.
🏛️ Architecture Overview
📋 Prerequisites Before You Start
Windows 10 21H2+ or Windows 11. TPM 2.0 chip enabled in BIOS. Azure AD Hybrid joined or Entra ID joined. Must have an active Primary Refresh Token (PRT).
Active Directory with at least one Windows Server 2016+ DC. Azure AD Connect syncing to Entra ID. Microsoft Entra ID P1 or P2 licence. Intune licence per user.
On-premises Domain Admin account (for DC setup). Entra ID Global Admin or Hybrid Identity Admin (for cloud credential). Intune Administrator.
No on-premises PKI or Certificate Authority. No certificate templates. No NPS servers. Cloud Kerberos Trust eliminates the certificate dependency entirely.
🔧 Step-by-Step Deployment
-
Prepare the Domain Controller - Fix TLS & PSGallery
Open PowerShell as Administrator on a Domain Controller. Older Windows Server versions default to outdated TLS protocols, which causes PSGallery connections to fail. Run these commands first:
# Force TLS 1.2 - required on Windows Server 2016 / 2019 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # Install NuGet provider Install-PackageProvider -Name NuGet -Force # Register PSGallery if not already present if (@(Get-PSRepository | Where-Object { $_.Name -eq "PSGallery" }).Count -eq 0) { Register-PSRepository -Default Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted } # Update PowerShellGet then install the Cloud Kerberos module Install-Module -Name PowerShellGet -Force Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber⚠ Common Error on Server 2016 / 2019 If you see "Unable to find repository 'PSGallery'" or "TLS/SSL connection failed", the[Net.ServicePointManager]line above is the fix. This command must run in the same PowerShell session before any Install-Module call. -
Register the Cloud Kerberos Server on the DC
After the module installs, register the domain controller with Entra ID. This creates the AZUREAD Kerberos server object in your AD that issues cloud-aware tickets:
# You will be prompted for two sets of credentials: # 1. DomainCredential - your on-prem Domain Admin account # 2. CloudCredential - your Entra ID Global Admin / Hybrid Identity Admin Set-AzureADKerberosServer ` -DomainCredential (Get-Credential) ` -CloudCredential (Get-Credential) # Verify it registered correctly: Get-AzureADKerberosServer # Expected: IsDefault=True, CloudDisplayName=[your tenant domain]🛠️ Multi-Domain Forests If your AD forest contains multiple child domains, runSet-AzureADKerberosServeronce per domain on a DC in that domain. The registration is not forest-wide — each domain needs its own cloud Kerberos object. -
Create the Entra ID Pilot User Group
Before touching any Intune policy, create the group that will scope your entire pilot rollout. In Entra ID (portal.azure.com) → Groups → New Group:
# Group configuration: "Group Type": Security "Name": Windows Hello for Business Users "Membership Type": Assigned # Add 10-20 pilot users as members # DO NOT add all users yet - validate pilot first # Optional: verify via PowerShell Get-MgGroup -Filter "displayName eq 'Windows Hello for Business Users'" -
Intune Policy 1 - Settings Catalog: Cloud Kerberos Trust
In Intune: Devices → Configuration → Create → New Policy → Windows 10 and later → Settings Catalog
Search for and enable these two settings:
# Settings Catalog - search and enable: # Category: Kerberos "Cloud Kerberos Ticket Retrieval Enabled": Enabled # Category: Windows Hello for Business "Use Cloud Trust For On Prem Auth": Enabled # Assignment: "Assign to": Windows Hello for Business Users (the group from Step 3) -
Intune Policy 2 - Custom OMA-URI Profile (4 Settings)
Create a second policy: Devices → Configuration → Create → Custom. Add these four OMA-URI entries. The MDMWinsOverGP setting is critical in environments with legacy Group Policy or SCCM — it forces Intune policy to win every conflict:
## Setting 1 - MDMWinsOverGP (forces Intune priority over GPO) Name: MDMWinsOverGP OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP Type: Integer Value: 1 ## Setting 2 - Activate Windows Hello for Business Name: UsePassportForWork OMA-URI: ./Device/Vendor/MSFT/PassportForWork/8858cc88-8c0d-48e6-b87c-dcc34f48dc0f/Policies/UsePassportForWork Type: Integer Value: 1 ## Setting 3 - Enable Cloud Trust for On-Prem access Name: UseCloudTrustForOnPremAuth OMA-URI: ./Device/Vendor/MSFT/PassportForWork/8858cc88-8c0d-48e6-b87c-dcc34f48dc0f/Policies/UseCloudTrustForOnPremAuth Type: Integer Value: 1 ## Setting 4 - CRITICAL: Enforce TPM 2.0 hardware key storage Name: RequireSecurityDevice OMA-URI: ./Device/Vendor/MSFT/PassportForWork/8858cc88-8c0d-48e6-b87c-dcc34f48dc0f/Policies/RequireSecurityDevice Type: Integer Value: 1🔗 Reference: Microsoft Learn These OMA-URI values are documented in Microsoft's official Hybrid Cloud Kerberos Trust deployment guide. The GUID8858cc88-8c0d-48e6-b87c-dcc34f48dc0fis the PassportForWork policy area identifier used in all CSP-based WHfB configurations. -
Intune Policy 3 - Account Protection (USER Scope - Most Critical)
Navigate to Endpoint Security → Account Protection → Create Policy → Windows 10 and later → Account Protection template. This policy activates WHfB and defines PIN security rules. It must be assigned to Users, not Devices — assigning to Devices is the single most common deployment failure.
🔴 User Scope is Mandatory — Not Optional If you assign this policy at Device scope, registry keys write to HKLM but the user context never receives the enrollment trigger. Users see no prompt. No error. Just permanent non-enrollment. The policy must target the user group, not a device group.
🔎 PIN Policy Configuration Reference
Every setting in the Account Protection policy has a specific rationale tied to a compliance standard. Do not adjust these values without understanding the regulatory impact:
| Setting Name | Recommended Value | Standard | Rationale |
|---|---|---|---|
| Enable Windows Hello For Business | True | All | Activates the feature. User-scoped assignment mandatory. |
| Use Windows Hello For Business | True | Enforces WHfB as the primary sign-in method. | |
| Require Security Device (TPM 2.0) | ⚡ True - CRITICAL | NIST AAL3 / NIS2 | Keys stored in hardware TPM, not software. Phishing-resistant. Without this = compliance failure. |
| Enable PIN Recovery | True | ISO 27001 A.17 | MFA-secured recovery. Reduces helpdesk tickets. Protects availability. |
| Minimum PIN Length | 8 characters | NIST 800-63B §5.1.1.2 | 6 is baseline minimum; 8 recommended for AAL2+ environments. |
| Maximum PIN Length | 127 characters | NIST 800-63B | Allows users to use passphrases instead of short PINs if preferred. |
| Special Characters | Required | ISO 27001 / SOC2 | ISO and SOC2 auditors expect at least one special character. Prevents trivial numeric-only PINs. |
| Uppercase Letters | Allowed | NIST 800-63B | "Allowed" not "Required" reduces friction while maintaining security posture. |
| Lowercase Letters | Allowed | NIST 800-63B | Same as above. Full character set permitted. |
| PIN Expiration | Not Configured | NIST 800-63B §5.1.1.2 | NIST explicitly recommends against forced rotation. Expiration leads to predictable increments: 1111 → 1112 → 1113. |
| PIN History | Not Configured | NIST 800-63B | Not needed since expiration is disabled. History enforcement only matters when rotation is mandatory. |
🔴 The Three Silent Failure Modes
These are the failure patterns that affect 30–50% of WHfB Cloud Trust deployments. They share one trait: no error message, no alert, just no enrollment.
What happens: The Install-Module AzureADHybridAuthenticationManagement command fails or hangs on Windows Server 2016/2019.
Root cause: PowerShell defaults to TLS 1.0/1.1 on older Server versions. PSGallery (PowerShell Gallery) requires TLS 1.2+. Additionally, PSGallery may not be registered as a repository out of the box.
Fix: The four-line TLS + PSGallery block in Step 1 above. Run it in the same PowerShell session immediately before any Install-Module call.
What happens: All policies are deployed, devices are compliant in Intune, but users are never prompted to set up Windows Hello. WHfB remains disabled.
Root cause: The Account Protection policy was assigned to a Device group instead of a User group. Registry keys write to HKLM\SOFTWARE\Microsoft\Policies\PassportForWork correctly — but the per-user enrollment trigger never fires. The device sees the policy; the user never does.
Fix: Delete the device-scoped Account Protection policy. Recreate it and assign the group in the Users tab, not the Devices tab, of the assignment blade.
What happens: Policy arrives. PRT is valid. Azure AD join is confirmed. But enrollment still fails or falls back to software key storage.
Root cause A: TPM 2.0 is present but disabled in the device BIOS firmware settings. Get-Tpm shows TpmPresent=True but TpmReady=False.
Root cause B: In SCCM co-managed environments, if SCCM owns the Device Configuration or Resource Access co-management workloads, Intune's WHfB policies are silently ignored by design.
Fix A: Enter BIOS/UEFI firmware settings and enable TPM 2.0. Clear the TPM if previously owned by another system.
Fix B: In SCCM console: Administration → Cloud Attachment → Co-management Properties → move Device Configuration and Resource Access sliders to "Pilot Intune" or "Intune".
📋 Diagnostic Script — Smart WHfB Health Check
Run this script on any affected device (as SYSTEM or elevated Admin) to instantly identify which layer is blocking enrollment. Written by Souhaiel MORHAG.
📊 Intune Detection Script - Proactive Remediation
Deploy this as a Proactive Remediation in Intune (Devices → Remediations) on a daily schedule. The detection script exits 0 if healthy, 1 to trigger the remediation script. Written by Souhaiel MORHAG.
Detection Script
Remediation Script
🔒 Compliance & Regulatory Mapping
👤 FAQ - Common Questions
✅ Pre-Go-Live Validation Checklist
Run this validation at least 48 hours before expanding from pilot to enterprise rollout. All items must pass:
| Layer | Validation Check | Command / Verification | Status |
|---|---|---|---|
| On-Prem DC | Cloud Kerberos module installed | Get-Module AzureADHybridAuthenticationManagement | ✓ Listed / ✕ Missing |
| On-Prem DC | Kerberos server registered | Get-AzureADKerberosServer | Select IsDefault, CloudDisplayName | ✓ IsDefault=True / ✕ Not registered |
| Entra ID | Hybrid join & PRT active | dsregcmd /status | findstr "AzureAdJoined AzureAdPrt" | ✓ Both YES / ✕ NO on either |
| Intune | Settings Catalog policy assigned | Intune → Devices → Configuration — verify Cloud Trust profile assigned to pilot group | ✓ Assigned / ✕ Missing |
| Intune | OMA-URI custom policy assigned | Check MDMWinsOverGP = 1 and all 4 Passport URIs exist | ✓ All 4 present / ✕ Missing |
| Intune | Account Protection USER-scoped | Endpoint Security → Account Protection — confirm Users assignment (not Devices) | ✓ User scope / ⚠ Device scope! |
| Device | TPM 2.0 ready | Get-Tpm | Select TpmPresent, TpmReady, TpmEnabled | ✓ All True / ✕ Any False |
| Device | No GPO conflict | (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork").Enabled ≠ 0 | ✓ Not 0 or missing / ⚠ Value=0 blocks |
| Device | Hello container exists | Get-ChildItem "HKLM:\...\{D6886603...}" -Recurse | ✓ Containers found / — Not enrolled yet |
| Functional | On-prem share access | Sign in with PIN → try \\server\share → should open without password prompt | ✓ Opens cleanly / ✕ Auth dialog appears |
🔗 Official Documentation References
- NIST 800-63B Digital Identity Guidelines — Section 5.1.1.2 on memorized secrets (PIN length, rotation policy): pages.nist.gov/800-63-3/sp800-63b.html
- Microsoft Intune WHfB Policy Reference — All policy settings and OMA-URI values: learn.microsoft.com — Hybrid Cloud Kerberos Trust
- IntuneLearning.com Cloud Kerberos Trust — Community deployment reference: intunestuff.com — Cloud Kerberos Trust WHfB Intune