Blog Post

Core Infrastructure and Security Blog
7 MIN READ

Passwordless RDP Authentication for On-Prem Servers with Smart Cards (FIDO2 Security Key)

Farooque's avatar
Farooque
Icon for Microsoft rankMicrosoft
Apr 07, 2025

Enable secure, passwordless RDP access to on-prem servers using Smart Cards with FIDO2 Security Keys. This approach leverages Kerberos PKINIT and certificate-based authentication to enhance protection and eliminate password risks.

Hello Everyone, in my previous blog, I discussed how to use FIDO2 Security Key Passwordless Authentication with Entra or Hybrid Joined devices for Remote Desktop Connection. In this blog, we will dis...
Updated Apr 06, 2025
Version 1.0
Active Directory
Domain
fido2
passwordless
Passwordless Authentication
smartcard
MMVader's avatar
MMVader
MCT
Apr 11, 2025
First of all, this is totally unrelated to anything regarding FIDO. This is simply SmartCard Logon utilizing a multi-protocol combo card.
Secondly, you won't simply deploy ADCS (or Microsoft Certificate Server) onto an existing Windows box. ADCS is a critical identity management system (similar to Domain Controller and especially if you plan to use it for Smart Card Logon) and MUST be deployed, operated and secured as Tier 0 asset! If that CA system gets compromised, the forest is lost!
 
If you going to explain PKINIT basics and authentication flow, you should give the full information with the proper links (and not just leave important parts out): 
PKINIT as a Kerberos extension is defined in RFC 4556 and RFC 8636 and the Microsoft implementation is described in "MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol" (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pkca/d0cf1763-3541-4008-a75f-a577fa5e8c5b).
The requirements for enabling PKINIT are as follows:
1. All certificates used during PKINIT must chain to trusted root CAs
2. All issuing CAs used in PKINT must be in NTAuth Certificate store in Active Directory
3. KDC certificate must contain one of the following:
  • The OID for KDC Authentication (1.3.6.1.5.2.3.5).
  • The OID for Smartcard Logon (1.3.6.1.4.1.311.20.2.2).
  • The presence of the template name “DomainController” in the certificate.
4. Client certificate must contain one of the following:
  • Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
  • Client Authentication (1.3.6.1.5.5.7.3.2)
  • PKINIT Client Authentication (1.3.6.1.5.2.3.4)
The authentication flow during interactive logon using a Smart Card is described in detail here: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pkca/53dd48a1-8325-4c0f-971f-d8c538d07f96.
 
When creating a certificate for the Domain Controller, we advice to limit the certificate EKUs to least requirements, which normally leads to only have "KDC Authentication" and "Server Authentication" in the Domain Controller Certificate (at least this is enough for PKINIT).
For the User (Smart Card) certificate, we usually advice to again enable least requirements at certificate template level:
  • Purpose: Signature and Smart Card Logon
 
There is normally NO need for the following certificate template settings:
  • Use existing key for automatic renewal of smart card certificates (this should only be enabled if the smart card is very short of key storage and no management process is available to refresh/re-initialize the smart card)
  • Prompt the user during enrollment and require user input when private key is used (smart card is anyway asking for PIN)
 
At the cryptography tab, the CSP or KSP is based on the smart card vendor (not all cards are working with the Microsoft CSP/KSP). If vendor-based CSP or KSP is needed, it must be installed everywhere where the smart card is used to logon to.
 
Also, there is no need to start smart card enrollment using certreq. Normally, we advice to use a certificate management system to keep control about the issued certificates and have an full audit trail. If that is not required, simply start certmgr.msc to request the certificate.
 
When using the smart card to logon to any system, for most vendors, you'll need to install the appropriate minidrivers locally and at the remote systems, you are connecting to. In addition you'll have to ensure that smart card redirection is enabled on your RDP client.