Microsoft Remote Desktop Authentication with Yubikey¶

References¶

Using a Yubikey through an RDP Session. SOLVED - Reddit

My Yubikey hardware was not being seen on my VM connected over RDP. There as an older post about this, but it is now locked so I am creating a new one to share my findings.

First, you need to make sure your RDS Server settings are configured to allow Smart Card redirection. There is a setting "Do not allow smart card device redirection" and it was Enabled. I love these backward settings. You need to disable do not allow.

Also make sure your RDP Client is set to share Smart Cards.

Second, you will need to open up the Yubico Authenticator on the remote machine, access the settings screen and open the Interface section. Change the Interface to "CCID - Custom Reader" and pick a reader from the Connected Readers drop down. Once selected click the text "USE AS FILTER" to copy it down to the Custom reader filter field. Click APPLY and you should be able to use the authenticator as if it was on your actual desktop.

I hope this helps others save all the hours we spent trying to track this down.

---

The complete guide to RDP with Security Keys (PC)¶

https://swjm.blog/the-complete-guide-to-rdp-with-yubikeys-fido2-cba-1bfc50f39b43

Tired of constantly typing in passwords or using clunky two-factor authentication like OTP to access your Remote Desktop? With the inclusion of “web accounts” in the Microsoft RDP client, you can now use a FIDO2 security key to authenticate to an RDP session. Keep reading to find out how!

Background and Scope¶

Have you ever had one of those “wow” moments where you’re just blown away by something that seems small, but makes a huge difference? Well, that happened to me recently when a colleague shared a video of how to use FIDO2 to authenticate an RDP connection.

Now, I know this might not sound like a big deal to most people, but for those ‘in the know’’, it’s huge; Not only is it a testament to the maturity of FIDO2 (and a sense of reward for those who has worked so hard to drive its adoption), but it also means that there is now a great(er) alternative to the otherwise favored Certificate-Based Authentication (CBA) for RDP security.

In this guide, I’ll walk you through the process of configuring RDP for FIDO2 authentication. And if for some reason FIDO2 isn’t an option for you, I’ve also included instructions for using Certificate-Based Authentication as a backup. Both of these methods are considered phishing-resistant and provide excellent security and usability.

[Fig. 1] FIDO2 (and CBA) for RDP with a multi-protocol security key (YubiKey).

YouTube - How-to: RDP with FIDO2 security keys!

RDPAAD protocol

Understanding implementation choice(s)¶

There are multiple options available for implementing hardware-backed multi-factor authentication (MFA) to secure Remote Desktop Protocol (RDP) sessions. These include Certificate-Based Authentication (CBA) compliant with the PIV (FIPS-201) standard, as well as FIDO2 (passkeys).

The selection of a particular method may depend on preference, but is often influenced by the specific constraints and requirements of the IT environment. To determine what approach to use given your circumstances, consult the following diagram [Fig. 2]:

[Fig. 2] Configuration choice (or necessity) for high assurance authentication over RDP.

RDP with a security key (FIDO2)¶

It has been possible to use FIDO2 within an RDP session for some time now. This has allowed organizations to for example authenticate web apps inside the session using USB redirection.

Now, with the new RDPAAD protocol and the inclusion of a “web account” selector in the Microsoft RDP client it is also possible to use FIDO2 to authenticate the RDP session itself.

[Fig. 3] Authenticating to RDP with a FIDO2 security key.

YouTube - Authenticating to RDP with a FIDO2 security key

For this to work you will need to meet the following prerequisites:

• Your client is Windows 10 or Windows 11 with the latest and greatest updates including the “22H2" update package(s)
• The remote host is either Windows 10, Windows 11, Windows Server 2022, again with all the relevant updates!
• The remote host must be Entra-joined / Hybrid Entra-joined
• The remote host must be accessible over NETBIOS or FQDN

Assuming the above requirements are met we can go ahead and configure and then test RDP using FIDO2 as the authentication method. If you cannot meet said requirements, have a look at the next major section on CBA/PIV.

Add your user as a Remote Desktop user¶

On the target host (e.g. the ‘session host’):

1. Press the Windows key and start typing “PowerShell” and then select PowerShell from the filtered list [Fig. 4]
2. Enter the following command (modify the UPN as applicable): Add-LocalGroupMember -Group "Remote Desktop Users" -Member "AzureAD\sue@swjm.blog" and then press ‘Enter’ [Fig. 5]
3. Close PowerShell.

[Fig. 4] Start PowerShell.

[Fig. 5] Add the user to the list of remote desktop users allowed on the target host.

Requiring MFA and controlling the Session with Conditional Access¶

At this point you will want to think about access control, including session life and re-authentication intervals.

1. Open a browser and navigate to Entra ID
2. Once logged in, expand Protection (left) and select Conditional Access
3. Under ‘Conditional Access’ click + Create new policy (top) [Fig. 6]
4. Give the policy a meaningful name, e.g. “Require phishing-resistant MFA for RDP” or “Require smart card for RDP” [Fig. 7]
5. Under ‘Users’ select Include and then make a selection as appropriate (e.g. all users or a selected group) [Fig. 8]
6. Under ‘Target resources’ select Cloud apps from the dropdown menu followed by selecting (radio button) select apps and then click ‘Select’ and choose Microsoft Remote Desktop with Id a3a365df-50f1-4397-bc59-1a1564b8bb9c from the list and click Select [Fig. 9]
7. Under ‘Grant’ select Require authentication strength followed by either selecting the broader (1) “Phishing-resistant MFA” or a specific strength e.g. (2) “YubiKey” (instructions here) and then click Select [Fig. 10]
8. Under ‘Session, select Sign-in frequency as appropriate [Fig. 11]
9. Lastly click ON in the ‘Enable policy’ toggle [Fig. 11] and then Create.

[Fig. 6] In Entra Conditional Access, select ‘+ Create new policy’.

[Fig. 7] Give the new policy a name summarizing its controls.

[Fig. 8] Under ‘Users’ select what users will be affected by the controls.

[Fig. 9] Under ‘Cloud apps’ select the ‘Microsoft Remote Desktop’ app.

Create and authenticate an RDP session¶

On your Windows 10/11 client (e.g. the ‘local PC’):

1. Press the Windows key and start typing “RDP” and then select Remote Desktop Connection from the filtered list [Fig. 12]
2. In the RDP client click to select the ‘Advanced’ tab (right hand side) [Fig. 13]
3. In the ‘Advanced’ view, under ‘User authentication’ check the box Use a web account to sign in to the remote computer [Fig. 14]
4. Click to select the ‘General’ tab (left hand side)
5. Provide target host name (NETBIOS/FQDN) and username (UPN) and (optionally click Save) then click Connect (or hit the ‘Enter’ key) [Fig. 15]
6. In the browser window select or input account name [Fig. 16]
7. Insert your FIDO2 security key (if not already present) [Fig. 17]
8. Provide PIN and click OK [Fig. 18]
9. Touch the security key [Fig. 19].

The user is logged in [Fig. 20]✔️

RDP with a security key as a smart card (PIV/CBA)¶

Using Certificate-Based Authentication (CBA) for RDP isn’t new, but a CBA (PIV) capable security key like the ***YubiKey 5*** has a several benefits over a legacy (ISO) smart card. This includes using the authenticator without card readers and using it with mobile devices over NFC or USB-C/Lightning. In fact:

Certificate-Based Authentication with a security key (such as the multi-protocol YubiKey) has both great security, great usability as well as great use case coverage including Windows logon, privilege escalation, RDP, secure email and mobile app authentication.

YouTube - Authenticating to RDP with CBA using a security key

Fig 21 - Authenticating to RDP with the YubiKey as a smart card.

For this to work you will need to meet the following prerequisites:

• You have a “PKI” (an issuing Certificate Authority or ‘CA’)
• Certificates are issued to Domain Controllers (‘Kerberos Authentication’ or ‘Domain Controller’) and to the user’s PIV capable security key (‘smart card logon’)
• “Ideally” (see Troubleshooting) the CA root certificate is trusted by the local host (the connecting computer) and CRL’s can be accessed by the host.

Add your user as a Remote Desktop user¶

On the session host (the target Windows machine):

1. Press the Windows key and start typing “PowerShell” and then select PowerShell from the filtered list
2. Enter the following command (modify the UPN as applicable): Add-LocalGroupMember -Group "Remote Desktop Users" -Member "sue" and then press ‘Enter’
3. Close PowerShell.

Create and authenticate an RDP session¶

On your Windows 10/11 client (e.g. the ‘local PC’):

1. Press the Windows key and start typing “RDP” and then select Remote Desktop Connection from the filtered list
2. In the ‘General’ tab, provide target host name (NETBIOS/FQDN) and username (UPN) and (optionally click Save) then click Connect (or hit the ‘Enter’ key) [Fig. 22]
3. Provide PIN (6 digits!) and click OK (or hit the ‘Enter’ key) [Fig. 23]

The user is logged in [Fig. 24]✔️

Troubleshooting¶

This section covers common connection problems, errors and warnings that you may come across using CBA (PIV). The section will be updated continuously.

🚩**Cross-domain RDP or RDP from non-Windows clients with PIV/CBA **When doing RDP across Windows domains, from non domain-joined Windows clients, via “jump hosts” or from Mac OS, Linux and thin clients, Certificate-Based Authentication (CBA) may fail because of Network Level Authentication (NLA) requirements on the target host.

Importantly, NLA attempts(!) to perform authentication on the client which may not always be possible or feasible given the prerequisites on certificate trusts, Kerberos and Domain Controller “line-of-sight” to do so.

If you do need NLA and your client is Windows-based, then you can meet prerequires through additional configuration, including the:

• Distribution of root certificate to RDP client
• Distribution of KDC (DC) certificate to RDP client
• Creation of a KDC proxy
• Making CRL’s publicly available

Certainly, if smart card authentication is enforced, then you may select to turn off NLA to work around these limitations. Do note that as NLA was designed to address the risk of Denial of Service (DOS) attacks you will want to use other controls to limit that attack vector.

🚩 **“The certificate is not from a trusted certifying authority” **This error (a warning, really) commonly happens if the local PC (client) and the session host (server) are on different domains and the certificate chain of the remote host cannot be checked / the issuing CA is not trusted by the connecting client.

In a lab/test environment you may simply connect anyway or view and install the certificate in the store for trusted root certificates (computer context). This will take care of the next warning as well by the way.

In a production context, this warning is best resolved by exporting the CA certificate and using your tools of choice to make it available to clients at scale.

🚩 **“A revocation check could not be performed for the certificate” **Again, if the local PC (client) and the session host (server) are on different domains you may see this error as the client is not able to fully verify the servers certificate for lack of access to a Certificate Revocation List (CRL).

If you are confident about why the warning is shown, you may select Yes to the question: “Do you want to connect despite of these certificate errors?”.

To fix this warning you will need to make a Certificate Revocation List Distribution Point available to external clients, for example on an internet facing web server.

🚩 **“The server name on this certificate is incorrect” **One beginners mistake why this warning happens is using an IP address instead of server name or FQDN. As this error will present with requested and actual server name (according to its certificate) so it is rather easy to check for errors.

🚩 **“Requested Key Container is not Available” **This error can be seen if the local PC (client) and the session host (server) does not both have the YubiKey Minidriver installed. For more information see this article.

🚩 **“The sign-in method you’re trying to use isn’t allowed” **If you get this error my bet is you´re trying to RDP to a domain controller with an account that is not a domain administrator. You could also have a group policy restricting you from accessing the target host.