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