Your admins sign in to their laptop with a fingerprint for email and Teams. Then they need to run an elevated console as their privileged account - and there is no Windows Hello credential for that account, so they are back to typing a password, or switching users, or running a whole separate machine. Windows Hello for Business (WHfB) dual enrollment solves exactly this: one device, two Hello credentials, elevate with a PIN. It is powerful, it is narrow, and it comes with a hard requirement that surprises everyone - it only works on certificate trust.
The problem: no Hello credential for the admin account
By design, Windows does not enumerate other users' WHfB credentials from within a signed-in user's session. That is a security feature - it stops one user seeing or using another's Hello credential. But it also means an administrator signed in with their day-to-day account cannot pick their privileged account's Hello credential to elevate. So elevation falls back to a password, which is the one thing passwordless was supposed to remove.
Why it happens - and the requirement nobody expects
Dual enrollment lets a single person enrol both their non-privileged and privileged accounts for Hello on the same device, then elevate to the privileged account with its PIN. But it is built on WHfB's smart-card emulation layer, and that ties it to specific deployment shapes:
| Requirement | Value |
|---|---|
| Trust type | Certificate trust only - not key trust, not cloud Kerberos trust |
| Deployment type | On-premises or hybrid |
| Join type | Domain join or Microsoft Entra hybrid join |
| Timing | Must be configured before either account provisions Hello on the device |
How to verify prerequisites
Confirm the device is on certificate trust and correctly joined before you start. A WHfB certificate-trust device has a Hello logon certificate (Passport-provider key, Smart Card Logon EKU, issued by your enterprise CA) and the cert-trust policy set. And dsregcmd /status must show the right join state:
The fix: two configuration steps
Step 1 - Let the privileged account write its key past AdminSDHolder
Privileged accounts are protected by AdminSDHolder: every hour, Active Directory compares the security on protected users/groups against the AdminSDHolder object and resets anything that differs. The normal WHfB delegation gives the Key Admins group read/write on msDS-KeyCredentialLink at the domain root - but for a Domain Admin, AdminSDHolder strips that permission back off within the hour, so their Hello key can never persist. You fix it by granting the permission on AdminSDHolder itself:
Then trigger security-descriptor propagation immediately (rather than waiting the hour) by setting RunProtectAdminGroupsTask = 1 via ldp.exe against the PDC-emulator DC.
Step 2 - Enable enumeration via Group Policy
This is a Group Policy-only setting - there is no CSP equivalent, so you cannot deploy it from Intune.
- Open Group Policy Management Console (
gpmc.msc). - Right-click the OU containing the admin workstations › Create a GPO in this domain, and Link it here... › name it (for example WHfB - Dual Enrollment).
- Right-click the new GPO › Edit.
- Navigate to Computer Configuration › Administrative Templates › Windows Components › Windows Hello for Business.
- Double-click Allow enumeration of emulated smart cards for all users › set Enabled › OK.
- Restart the targeted computers so the policy takes effect before either account provisions Hello.
Create a GPO linked to the organizational unit (OU) holding the admins' computers and enable:
| Group policy path | Setting | Value |
|---|---|---|
| Computer Configuration \ Administrative Templates \ Windows Components \ Windows Hello for Business | Allow enumeration of emulated smart cards for all users | Enabled |
Restart the targeted computers, then enrol in the right order: sign in as the privileged user first and set up Hello, then sign out, sign in as the non-privileged user, and set up Hello.
AdminSDHolder step is only needed for accounts that AdminSDHolder protects - members of Domain Admins, Enterprise Admins and other privileged groups. For a standard admin account used purely to elevate on a workstation, the normal domain-root Key Admins delegation on msDS-KeyCredentialLink already covers it, and you can skip the dsacls step.certutil -deletehellocontainer as each user) and re-provision after the policy is in place - otherwise the existing containers were not created with the dual-enrollment flag.How the admin uses it
Once both credentials are enrolled, the admin signs in with their non-privileged account for normal work. To elevate, they choose Run as different user or Run as administrator, pick the privileged account, and authorise with that account's PIN - no password. For command line, runas.exe /smartcard does the same:
Proof it worked
Here is a real run of Get-DualEnrollmentReadiness.ps1 from this series, against a device on cloud Kerberos trust - the honest "not eligible" case, since dual enrollment requires certificate trust specifically:
This is the single most common reason dual enrollment "does not work" - a device that is correctly, deliberately on cloud Kerberos trust (the recommended model for almost everyone) will always fail this check, because dual enrollment predates cloud trust and was never extended to support it. If you see this result, the fix is not more configuration - it is confirming whether dual enrollment is really the right tool, or whether Privileged Access Workstations are the better answer for this admin. Success looks like this: the admin, signed in as their standard user, launches an elevated tool, selects the privileged account, and is prompted for a PIN rather than a password - and the elevated process runs under the privileged identity. No fast-user-switching, no second laptop, no password typed.
References
- Windows Hello for Business dual enrollment
- WHfB policy settings (Allow enumeration of emulated smart cards)
- Privileged Access Workstations (the recommended alternative)
- AdminSDHolder and protected accounts in Active Directory
Script for this post is in Daily-Tasks.