Overview and Introduction
The following guide describes how to set up smart cards with an on-premises (on-prem) Active Directory (AD). A brief description of smart cards will be followed by details relating to the applicable use cases, and finally detailed instructions on how to ultimately implement phishing-resistant authentication. It is important to note that FIDO2 and other forms of remote authentication are considered out of scope for the purposes of this article, and the focus will instead be on smart cards only. This guide assumes that Microsoft Azure and/or Office 365 are not in use, or that their use is completely disconnected from the on-prem AD. Finally, for smart card deployments that involve hybrid architectures where the Microsoft Azure Active Directory (AAD) is in use, see "Phishing-Resistant Authentication for Hybrid architectures”. For clarification on what a hybrid environment entails, please refer to Yubico's definition of hybrid.
A smart card is a physical electronic authentication device used to control access to resources. It is typically a plastic credit card-sized object with an embedded chip, although can even be found in modern passports, mobile devices under the guise of a SIM card, “smart” devices classified within the Internet of Things (IoT) and notably, many versions of the YubiKey. Smart cards typically provide the ability to connect to physical card readers and terminals, but also contactless capability within a small range using Near Field Communication (NFC). Smart cards are ubiquitous across many types of organizations both large and small, and are currently adopted by the highest institutions at national levels, offering strong authentication leveraging sound cryptographic principles.
Importantly, a prerequisite for this architecture requires enterprises to have established PKI lifecycle processes and be able to create, enroll, renew, revoke, publish Certificate Revocation Lists (CRLs) and handle all the other standard smart card processes. These processes may be handled by a third party Certificate Management System (CMS), but the native capabilities within AD and Active Directory Certificate Services (AD CS) may also suffice in many circumstances. Please also see the supplemental guides for links to sources that describe these prerequisites.
In this document, the term certificate-based authentication (CBA) is used interchangeably with smart card authentication, and can refer to a number of different authentication protocols. The section "Supported use-cases" of this document will provide additional context for how CBA is used as seen in Figure 1. For each supported use case, the different protocols supported (if applicable), and if that use case can be leveraged to support single-sign-on and enable more services for use with CBA.
Figure 1. Phishing Resistant On-Premises Authentication for Windows using Smart cards
Smart cards, in conjunction with Windows, enable customers to use their own Public Key Infrastructure (PKI) to support X.509 certificate-based sign-on to AD joined workstations and applications. Smart card support is currently included in all versions of Windows not classified as end-of-life, and can be utilized by all YubiKey models that include Personal Identity Verification (PIV). It should be noted that this smart card capability is natively supported in both AD and Windows, and thus no 3rd party software is required, although middleware solutions may provide additional features. Windows even includes a basic Certificate Authority (CA) that may be able to satisfy modest certificate management needs of small to medium sized enterprises, although larger enterprises may require a much more advanced toolset.
Figure 1 shows the relationships between the major components in an on premises environment that uses smart cards for authentication, and uses an on premises Active Directory as the only identity provider. The user will connect the YubiKey, which contains a digital certificate with their identity information, to a computer or mobile device by plugging it into an available USB or Lightning port, or connecting to it wirelessly using NFC. Once the YubiKey is connected and unlocked with a PIN, it can be used to sign in to Active Directory joined Windows and MacOS devices, and used for browser based certificate-based authentication flows with workstations and mobile devices. Active directory has been preconfigured with a trusted smart card issuer certificate authority chain, either through Windows’ native Active Directory Certificate Services (AD CS) or a 3rd party Certificate Management System (CMS) and is able to check the Certificate Revocation List(s) to ensure certificates are still valid. The PKI lifecycle processes, which play a critical role in ensuring that the correct certificates are provisioned and revoked in a timely manner, govern the circumstances around issuance, renewal and provisioning of the digital certificate contained on the Yubikey, as well tracking certificate revocation and publishing new CRLs in a timely manner.
Further, Active Directory Federation Services (AD FS) is a key component of an on-prem smart card deployment, because it enables smart card authentication with clients and services that are not connected to the same network as AD.
Some of the acronyms and key terms used throughout the guide are defined in the glossary table below, to help provide clarity and context.
Term |
Definition |
AD |
Active Directory |
AD FS |
Active Directory Federation Services |
CA |
Certificate Authority |
CBA |
Certificate-Based Authentication |
CMS |
Certificate Management System |
CRL |
Certificate Revocation List |
FIDO2 |
Fast IDentity Online version 2 |
IoT |
Internet of Things |
IWA |
Integrated Windows Authentication |
mTLS |
Mutual Transport Layer Security, a version of TLS where |
NFC |
Near Field Communication |
On-Prem |
On-Premises |
PIV |
Personal Identity Verification |
PKI |
Public Key Infrastructure |
RDP |
Remote Desktop Protocol |
SSO |
Single Sign-On |
TLS |
Transport Layer Security |
X.509 |
A standard defining the format of public key certificates, |
Supported use cases
- Sign-in to on-premises Integrated Windows Authentication (IWA) applications
- Sign-in to Active Directory joined Windows 10 & 11 workstations
- Sign-in to Active Directory joined Windows Servers
- Sign-in to Active Directory joined Mac OS workstations
- Remote sign-in to Active Directory joined Windows 10 & 11 desktop sessions
- Remote sign-in to Active Directory joined Windows Server desktop sessions
Where supported
Chrome, browsers |
MS 365 native apps |
IWA Apps (File Sharing, Databases, etc) |
Device sign in |
Remote Desktop and Azure Virtual Desktop |
|
Windows |
Not Applicable |
Not Applicable |
Not Applicable |
Not Applicable |
Not Applicable |
Windows |
Not Applicable |
Not Applicable |
Not Applicable |
Not Applicable |
Not Applicable |
Windows AD |
Yes |
Not Applicable |
Yes |
Yes |
Remote Desktop Only |
Windows non- |
Yes |
Not Applicable |
No |
No |
No |
MacOS |
Yes |
Not Applicable |
No |
Yes |
No |
Android |
No |
Not Applicable |
No |
No |
No |
iPhone |
Yes (Safari Only) |
Not Applicable |
No |
No |
No |
iPad |
Yes (Safari Only) |
Not Applicable |
No |
No |
No |
ChromeOS |
Yes* |
Not Applicable |
No |
No |
No |
* May require 3rd party extension
Prerequisites and Requirements
Active Directory Smart Card Authentication requirements
For on-prem device sign in and SSO to traditional Windows applications that can utilize IWA, generally only PKI and AD are required.
- A functional PKI, complete with CA and certificate lifecycle processes
- One or more Certificate Revocation List (CRL) accessible by all parties in authentication
- AD support for smart card authentication has been configured
Active Directory Federation Services requirements
For organizations that need to support external or mobile devices, access to applications hosted by other organizations or in the cloud, and to protect legacy applications that aren’t capable of supporting IWA, AD FS is required. Note that AD FS and the optional Web Application Proxy are both included with Windows Server.
- A complete Active Directory Federation Services deployment with internal AD FS servers and (optionally) externally available Web Application Proxy servers
Using Smart Cards on iOS or iPadOS Devices with AD FS
- Yubico Authenticator is required on iOS/iPadOS when using YubiKeys over NFC or Lightning
iOS and iPadOS |
iPadOS (USB-C) |
|
Browser-based web apps (Safari or |
No companion apps |
Deployment Guidance
Below are the step-by-step instructions to assist the setup and deployment of smart cards, in addition to helpful supplemental guides for additional reading. Finally, a troubleshooting section can also be found below, outlining common and known issues that may be encountered during implementation or setup. In the event these materials still do not provide enough information, please contact our helpful Yubico Support team for additional guidance, or Yubico Sales team for assistance with purchasing YubiKeys and other Yubico devices.
High level step-by-step instructions
- Ensure PKI Infrastructure is trusted by the Windows Active Directory (AD) Domain
- Ensure that the CRLs are published in a location that is accessible by all machines performing smart card authentication for local device logon and remote desktop logon
- Deploy the smart card minidriver to Windows clients
- Configure AD to enforce smart card authentication on a per-user or per-machine basis. See the article “Transition Guide: Passwords or OTP to Smart Cards for On-Prem Windows Authentication” for more guidance if there is already an OTP solution in place that smart cards will replace
- (Optional) Deploy AD FS internally to allow smart card authentication to federated relying parties
- (Optional) Deploy AD FS Web Application Proxy externally to allow mobile and remote devices to authenticate to externally available resources
- (Optional) Deploy AD FS Web Application Proxy to enable access to legacy web applications that don’t support smart card authentication, or allow mobile devices to access web applications that only support Integrated Windows Authentication (IWA)
Supplemental Guides
- The YubiKey Smart Card Deployment Guide provides step by step instructions on building a complete proof of concept environment, including a Windows Active Directory Certificate Services server, and configuring appropriate templates for Smart Card certificate issuance.
- Deploying the YubiKey Minidriver to Workstations and Servers contains detailed information about a variety of methods for deploying the YubiKey Minidriver.
- The Yubico Developer's PIV page contains information and resources for developers on how to incorporate PIV logon into their own applications.
- macOS Native Smart Card Support for Logon with Windows Server describes how to configure MacOS clients and AD CS certificate templates to enable smart cards log on to MacOS devices.
Troubleshooting
- Smart Card Basic Troubleshooting contains information on troubleshooting a variety of common issues with using smart cards.
Implementation
For information on how to best utilize smart cards once they are set up, the additional resources below are available. Firstly, some best practice guidance to help ensure both optimal deployment and maximum solution effectiveness. Next, some optional transition guidance to help migrate from one solution to one or more alternative deployments. And finally, some commonly asked questions and answers that may have not already been covered within the supplemental guides or troubleshooting sections.
Best Practices
Use a Hardware security module to secure root certificates for an Active Directory Certificate Services Deployment.
The overall strength of any smart card deployment will always be limited by how well the root certificates are protected. A default deployment of Active Directory Certificate Services uses a software solution to secure the root certificate, which makes it vulnerable to theft in a variety of ways. Using a hardware security module to store the private keys for a root certificate authority will help prevent a root key compromise, and help ensure that certificates can only be generated by authorized users. See the “YubiHSM2 for ADCS Guide” on docs.yubico.com for information on how to use the YubiHSM2 to secure your Active Directory Certificate Services deployment.
Additional Guides:
- Pre-provisioning a YubiKey for use with the YubiKey Smart Card Minidriver
- Enabling Smart Card in Firefox on Windows
- YubiKey: Deployment Considerations for Call Centers
- Smart Card PIN Unlock/Reset - Operational Approaches
- YubiKey PIN and PUK User Management on Windows
Transition Guidance
Transition Guide: Passwords or OTP to Smart Cards for On-Prem Windows Authentication
The most common scenario to be transitioning from when rolling out phishing resistant authentication with smart cards is either an OTP solution for their wide compatibility with legacy systems, or no MFA at all. In either case, the transition to smart cards is relatively straightforward. The process consists of:
- Enabling optional smart card authentication
- (Optional) Removing or reconfiguring OTP providers so that they do not require an OTP in addition to a smart card
- Provisioning smart card certificates for users
- Enforcing smart card authentication for specific users or services until all compatible use cases are enabled for smart card authentication
The Transition Guide - Passwords or OTP to Smart Cards for On-Prem Windows Authentication KB offers in depth guidance on how to ensure a successful transition to smart card authentication.