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?

35 Replies

Did you ever figure this out? Just installed 1809 and ran into the same message.

best response confirmed by Erik Moreau (Occasional Contributor)

This only pertains to certificate trust deployments and biometrics. Will WHFB work with rdp/rdweb while using a PIN?

I performed the steps in the guide after seeing this error and now WHFB has completely dissapeared as an option for RDP.  Just traditional UPN or Domain\user logon are the only options. I would love to go password-less, but it seems there is still some refinement required.

It would be nice to actually get a reply to one question I ask on this forum. 

RDP with Windows Hello for Business only works with certificate based deployments. Support for RDP with Windows Hello for Business PIN has been available for multiple releases. The changes in 1809 add support for biometric auth in addition to PIN.  

Unfortunately Microsoft documentation did not state that as a limitation for key trust deployments and Microsoft support didn't know that either. So we will have to switch to a certificate deployment in order to use PINs for RDP.
Please don't recommend keytrust everywhere, then make it incompatible with remote desktop. I can't tell you the irritation this created for us.

Certificates are vastly more complicated to set up and ADFS is mandatory for authentication, which we just found out after two weeks of troubleshooting with Microsoft. To be clear, with certificate trust, you can't be using SSO with Azure connect pass through, adfs must be used.

Very disappointing

I have also deployed Key Trust model on the guidance and understanding from Microsoft that it was the simpler, more modern and reliable method to use in a cloud focused future. You can imagine my disappointment to learn of the limitations with this choice after deployment. Even worse, the limitations are not listed in the documentation when advising what solution to consider during deployment.
The two most significant limitations are:
- Up-to 30 minute delay window for key's to be sync'd via AAD Connect
- Can't be used as an RDP authentication method
Though an irritation, the 30 minute sync would be a blessing if RDP worked. I can't put into words how absolutely irrate I was when we saw that RDP would not work with key trust, especially given that it's the preferred model.

It just cripples us.
has this been resolved? is it possible to use WhfB PIN (not certs!) to RDP login into a windows server joined to Azure AD Domain Services?

@jurajt  Nope, not as far as I know.  If it was resolved, and key-trust worked with RDP, I would be chugging margaritas and dancing on tables.

Sadly it still hasn't been fixed, and there is still little information available. I'm engaging Microsoft under our Unified Support to better understand what's happening in this space.

As of a few weeks ago there wasn't any action and we were speaking with senior engineers. The documentation that states that ADFS is an absolute requirement with key trust is because of our case unfortunately.

Previously there was some gray area where it was thought that AD Connect would be sufficient. Our original thought was that we would go passwordless with Windows hello for business combined with phone sign in for Office 365 Authentication, on the back of multi-factor Authentication width required biometric login.

We actually rolled it out with incredibly positive user feedback. We were heroes. And then RDP bit us in the arse.

I'd be happy with a registry key to disable/hide the PIN/Biometric login option from RDP while Microsoft work to make the Key Trust model work.

I can't find that group policy in MDMs such as Azure Intune or Office365 device management.
my devices run Windows 10 1909. any ideas?

@Azim null 

@Azim null wrote:

I performed the steps in the guide after seeing this error and now WHFB has completely dissapeared as an option for RDP.  Just traditional UPN or Domain\user logon are the only options. I would love to go password-less, but it seems there is still some refinement required.

For me I want to have access to PIN when using my Hyper-V VM in enhanced session mode, but Windows hello options disappear and only appear when using basic session mode in Hyper-V VM console.

@Clint LechnerThat AAD Connect comment was gold.  I was fuzzy too as it seemed no RA was required for the key trust model.  Regardless, based on all these comments, the idea that I might be able to get away with the key-trust model seems to be out the window especially since we have a brand new requirement to deploy a single new RDP based PAW (Privileged Access Workstation) that should only be accessed with WHfB credentials.  All I can say is I'm lucky all our servers are 2019 and workstations Win 10/1909.  Now to build the lab!  Krikey!

It's possible, but technically it's not key based trust anymore. You don't need ADFS, just configure key based trust, then continue the guide to set up an NDES server and deploy user certificates through Intune