Microsoft Technical Takeoff: Windows and Microsoft Intune
Oct 24 2022 07:00 AM - Oct 27 2022 12:00 PM (PDT)

Logging on to Remote Desktop using Windows Hello for Business & Biometrics

Regular Contributor

In the release notes for build 17713, support was announced for logging into remote desktop sessions using biometrics via windows hello.  I have a few questions I'm hoping someone can answer:


The way the blog post is worded, it's not clear whether the 'new' part of this is strictly related to biometrics, or if using Windows Hello to log into a remote desktop server is completely new.  Was it previously possible to use Windows Hello with a PIN to log in to a remote desktop session?  If so, is there any documentation on this available?


In the example used in the blog post, the Remote Desktop connection is from a Windows 10 client to a Windows Server 2016 server.  Is Server 2016 required, or will this work with older server OS versions?


Does it matter which type of deployment (Key-Trust vs Certificate-Trust) is used for Windows Hello for business?  


I've tried using this feature in my environment, to connect from a client running build 17713 to a Server 2016 server, but get an error "The client certificate does not contain a valid UPN. . . " (screenshot below)hello_rdp3_surface.png


Any idea what would cause that?  

Have any Insiders out there been able to use this new feature successfully?

42 Replies
RDP does not work with key trust.
Our users love passwordless. I said fine, you don't like multifactor, how about if I make it easy and take away passwords and go biometric? It was like one of those videos where the guy is getting passed around on top of the crowd, like a hero coming home after saving the princess and slaying the dragon. Implemenr it all correctly with enough options and nobody should have issues. Of course, until you use RDP. What did we do? Hardware tokens for those in need of RDP... then I heard the championship music again....
I know, but as I said, when you deploy an NDES server after you have configured key based trust, you can distribute WHFB certificates to users through Intune. Now you have certificate based trust, and RDP works
You're a godsend - thank you for sharing!



How does this work exactly with NDES? Do you have a guide?

@Anders Gidlund you can follow the guide for using certificates with Azure AD Joined devices to enable SSO with Windows Hello for Business to on-prem (Using Certificates for AADJ On-premises Single-sign On single sign-on - Microsoft 365 Security | Mic...). For Azure AD Joined devices, AD FS cannot be used as a certificate RA so Intune and NDES have to be used to distribute certs. The method isn't unique to Azure AD Join and can be done with any modern managed device.

@Matthew_Palko sorry If I am dumb, but I just want to make this clear.

Im setting up a Key Trust because I do not and cannot use ADFS in our environment. Youre referring to a guide for a Certificate Trust setup.

Im using these guides:
Hybrid Key Trust Deployment (Windows Hello for Business) - Microsoft 365 Security | Microsoft Docs
Configure Hybrid key trust Windows Hello for Business - Microsoft 365 Security | Microsoft Docs

Do you mean that I can setup a Key Trust deployment without ADFS and then just install NDES like in the guide your linking to (starting from here: and then have functionality to login using WHfB to on-premises RDS servers?

@Anders Gidlund I think that’s what he’s saying.

this is what we’ve done and it works perfectly 

Great! I will try this! Thanks!

@Dani Halfin 

Great i live the fact the Microsoft links never work

The method that has seemed to work best for us is to enable Remote Credential Guard which works directly with Windows Hello for Business to provide SSO RDP. We made our environment all RCG friendly by applying the DisableRestrictedAdmin registry item and the "Remote host allows delegation of non-exportable credentials" GPO setting at the domain level, then applied the "Restrict delegation of credentials to remote servers" just to the laptops OU. If your RDP servers access other RDP resources internally, then you may want to apply RCG settings to those too to make nested RDP SSO.


The only issue is if you have any pre-2016 RDP servers, which don't support RCG, as clients will refuse to connect to any RDP server that doesn't support RCG (wish MS had an exception list for this!). A couple work arounds for these legacy RDP servers is, 1) to use the RDWeb Web Client for those services until such time as they can be migrated to 2016/2019, 2) keep a 2016+ RDP server without RCG as a jump-off point for those services.



I come with gifts for all! Gather round! Key-Trust + RDP = win!
fyi - we have this deployed in production
I saw that article and followed it, which was similar to what has already been posted about using endpoint mgr to deploy smart card certs to passport after the fact. The how-to for deploying them using an in-house CA was nice though.

It works, but had issue where RDP client would first pick the wrong cert and you would need to manually chose the correct cert so there is a cert ordering issue. Also, there is still the issue where only one RDP session can use the smart card cert at a time, is that for everyone or just me? We utilize multiple RemoteApp servers for line of business apps, so being able to log into multiple sessions simultaneously is needed.

Fix the certificate ordering issue and allow simultaneous access to the cert from multiple RDP sessions and then we might have a workable solution, but in the meantime we’re continuing to use Remote Credential Guard for domain computers which works very nicely except that RDP over UDP doesn’t work with it.

Crossposted on Reddit:

I've got a working key trust deployment and have created an AD CS template for user certificates as described in

After obtaining the user certificate, I attempt to connect to another Windows device via RDP. Hello takes facial recognition/fingerprint, but gives the message , "An authentication error has occurred. The client certificate does not contain a valid upn, or does not match the client name in the logon request."

However, if I select "more choices" and select the UPN-based security device credential it works. If I remove the cert, it breaks, which leads me to assume that certificate is working. Judging on the other options listed under more choices it looks like fingerprint and face are trying to pass domain\samaccountname instead of UPN. Has anyone figured out a workaround for this?
I believe the smart card login is defaulting to the key trust certificate rather than the smart card one you created. As my user base can’t even put up with picking a cert to login with, they want true SSO, I went with the Remote Credential Guard option on our WHfB devices which works like a charm.

@BusinessFish Bro that sounds good (using NDES to get certs synced with Intune) do you have any instructions?

Have you figure it out what the issue was?
I'm having the same issue

@Martin Lim yehea dawg I solved it.

Push this script to your devices from intune, it forces the machines to treat the certificates as smart cards and then uses them for RDP. Working like a charm for me :)

#Setting registry key to force WHfB certs to be treated as smart cards.
$RegistryLocation = "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork"
$keyname = "UseHelloCertificatesAsSmartCardCertificates"

#Test if path exists and create if missing
if (!(Test-Path -Path $RegistryLocation)){
Write-Output "Registry location missing. Creating"
New-Item $RegistryLocation | Out-Null

#Force create key with value 1
New-ItemProperty -Path $RegistryLocation -Name $keyname -PropertyType DWord -Value 1 -Force | Out-Null
Write-Output "Registry key set"