Windows Hello for Business (WHfB) provides a password-less experience for users to log into their Windows 10 or 11 device. However, a challenge remains when accessing remote systems. This can be via MMC console for example to access Active Directory Users and Computers. Or RDP access onto a remote server. We still need to provide a password to run these tools. How do we protect these credentials from compromise? This is where we can use a combination of WHfB dual enrolment with a certificate deployed to the WHfB container protected with the users PIN/Biometrics.
The end goal will be that we can log on with our high privilege user, enrol in WHfB, obtain a certificate that can be used for RDP access, save this certificate in our protected WHfB container and use this when logged on with a low privilege user. This can give us a passwordless RDP and remote admin console experience.
I don't want to re-invent the wheel, so this guide will be pulling together a couple of guides already in the WHfB deployment guides into a single solution with an overview of how to use the solution.
Note: Microsoft recommends that the best way to protect your high privilege credentials is to use a Privileged Access Workstation. Not exposing high privilege credentials on systems that are a target for attack removes the risk of those credentials being compromised. This article does not supersede that advice in anyway. But offers an alternative way to protect high privilege credentials.
Extra care should be taken when syncing high privilege accounts to AAD. Do not sync Domain Admin accounts for example. Please refer to Microsoft's "Securing privileged access Enterprise access model" for further information.
Out of Scope
Deploying the components for WHfB is out of scope for this guide. It is assumed this is already deployed and the reader understands how to enrol a user in WHfB via GPO or Intune. If you have not already deployed WHfB, please start here Windows Hello for Business Deployment Overview - Windows security | Microsoft Docs
1. Requirements
Pre-requisites:
- Hybrid joined windows 10/11 computer
- PKI with a modified certificate template issued
- Dual enrolment configured via GPO
- Standard and high privileged user synchronised to azure AD.
2. Deploying Certificates to Key Trust Users
Use this guide, Deploying Certificates to Key Trust Users to Enable RDP - Windows security | Microsoft Docs, to setup the required certificate on your PKI.
Key points:
- Duplicate the smartcard logon certificate
- Modify template to save the certificate into the “Microsoft Passport Key Storage Provider”
Note 1: Only complete the “Create a Windows Hello for Business certificate template”. Do not complete the “Requesting a certificate” stage just yet. The high privilege user will complete this.
Note 2: You can apply a security group to this new certificate template. Make sure you place your admin users into this group.
3. Deploy Dual enrolment settings
We will use this guide Dual Enrolment - Windows security | Microsoft Docs to setup dual enrolment. The key points here are:
- A modification to AdminSDHolder
- GPO to enable “Allow enumeration of emulated smart cards for all users”
Note: The GPO is a computer-based policy. Make sure you are scoping this to include the computer objects of your admin users.
4. Enrolling users
Once we have deployed the certificate template to our PKI and enabled the dual enrolment settings on our target PCs, we can now enrol the high privilege and low privilege user.
Note: The “allow enumeration of emulated smart cards for all users” setting needs to be in place before we enrol any user. If you have already enrolled your normal user for WHfB, then we need to remove this. We use a certutil command for this:
Certutil -deletehellocontainer
4.1 Admin user hello enrolment and certificate enrolment
- Sign in using your high privilege user and complete the windows hello for business enrolment. For security reasons, make sure to use a different pin than you will use for your standard user account.
- Using the section “Requesting a certificate” from the guide, Deploying Certificates to Key Trust Users to Enable RDP - Windows security | Microsoft Docs obtain the high privilege user certificate.
- Once enrolled, you will new see a new cert in the personal store, alongside your WHfB certificate, plus any other certificates issued by your environment.
4.2 Standard user WHfB enrolment
- Sign back in as the standard user and complete the WHfB enrolment.
- Done
Note. We do not need to enrol a certificate for this user. This user should not be doing using RDP with these credentials.
5. Effect of “Allow enumeration of emulated smart cards for all users” setting
Open the MMC.exe and add the certificate snap in. We will now see the certificate of the admin user in our personal store along with our own WHfB certificate. This allows us to select this certificate for authentication.
Windows 10 allows for up to WHfB enrolments per device. This will allow multiple certificates to be issued and used by the standard user.
As you can see here, an additional three users have been enrolled and their WHfB protected certificates are available for use.
6. How to use the admin certificate
We can use this certificate for two purposes.
- Signing into an RDP session
- Launching an application as another user like an MMC console or an RSAT tool
6.1 Signing into an RDP session
When we need to enter credentials for an RDP session, selecting more choices, the admin user is available for selection because the certificate is in our personal store. Simply select the credential and enter the pin we setup during the admin user enrolment.
6.2 Launching application as another user like an MMC console or an RSAT tool
When we select run as different user, we will then get the option to select the admin credential under more choices. When we select that credential, we will be asked to provide the pin we setup during the hello enrolment for that user.
Conclusion
Using this method, we have achieved passwordless multi factor authentication for RDP and remote admin tools. This is MFA because the something we have is the device where the certificates are stored and the something we know is the PIN used to unlock the keys in the TPM to use these certificates. We are protecting these credentials as we are not exposing their passwords to potentially targeted and compromised machines.
Update: To address some of the comments below, I thought it best to add a footnote. This demonstration of the dual enrolment feature of Windows Hello for Business is by no way a replacement for a properly deployed and maintained zero trust strategy using amongst other things, a PAW/SAW and a tiering model. The guidance held within the above linked enterprise access model will provide all the protection for high privilege credentials you need. However not all environments are mature enough or have the manpower to take on such a project. As such, I see on a daily basis admins exposing their high privilege credentials on their daily workstation several times a day. We can combine several protection features like protected users, credential guard, FGPP, Kerberos hardening, smart card required for interactive logon for the high privilege accounts we use daily combined with NTLM rolling in 2016 DFL to now rotate that SCRIL password with this WHfB protected certificate feature. If we are already exposing our high privilege credentials on our daily workstations, then we can add an extra layer of protection to reduce the use of their passwords. If we enable SCRIL, we wont even know the password of that account anyway.
Without getting too deep in the WHfB technical weeds, this feature can only be physically used at the computer on which it is enrolled. If you were to RDP to the computer setup with dual enrolment and you try to elevate, you will not get presented with the option of selecting a security device credential to enter a pin. You won't be able to log onto the computer using WHfB at all. To try and compromise the pin, you physically need to have the device.
The pin is also protected via a physical TPM (if enforced by the admin and recommended to do so). This has the benefits of anti tamper and lockout policies. Once locked, requires the user to reset the pin and in doing so, will need to MFA. Windows Hello for Business Frequently Asked Questions (FAQ) - Windows security | Microsoft Docs
And just for some extra reading, Password vs Pin Why a PIN is better than an online password (Windows) - Windows security | Microsoft Docs
I hope you can see the benefit in using an approach like this. Thank you for reading and please leave a comment below if you have any questions.
