Overview and Introduction
The following guide contains information to help navigate the transition from a legacy on-premises (on-prem) Active Directory (AD) architecture to a hybrid architecture leveraging Azure Active Directory (AAD). A brief description of key components will be followed by details relating to the applicable use cases, and finally detailed instructions on how to ultimately implement a cohesive solution. It is important to note that an on-prem or cloud only architecture is considered out of scope for the purposes of this article, and the focus will instead be on hybrid (a combination of both). This guide assumes that enterprises already have an existing on-prem AD solution, but also that an AAD tenant is available. Finally, for deployments that involve federated AAD tenants with on-premises AD FS, see the transitional state hybrid architecture with on-premises AD FS and Azure AD.
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 containing a digital certificate that itself contains sensitive cryptographic information used to attest the identity of the bearer. The form factor of smart cards has evolved over the years however, and nowadays can even be found in objects such as passports, mobile devices, “smart” devices classified within the Internet of Things (IoT) and notably, many versions of the YubiKey. Smart cards are the foundation of an authentication archetype known as certificate-based authentication (CBA).
Importantly, a prerequisite for this architecture requires the enterprise to have established PKI lifecycle processes and be able to create, enroll, renew, revoke, publish Certificate Revocation Lists (CRLs) and handle all the 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 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. See the “Supported Use Cases” and “Where Supported” sections further down in the document for details on the supported use cases and which platforms they are supported on.
Figure 1. Transitional state hybrid architecture with on-premises Active Directory and Azure AD
Figure 1 shows the relationships between the major components in a transitional hybrid environment that uses smart cards for authentication and also leverages an AAD tenant. Yubico is considering the architecture in Figure 1 as transitional because the authentication is split between the cloud and on-premises.
Microsoft describes Azure AD (AAD) Certificate-Based Authentication (CBA) as a way for enterprises to allow or even require users to authenticate directly with X.509 certificates against AAD for workstations, applications and browser sign-in. The feature is notable because it enables the adoption of phishing-resistant authentication (namely smart cards) against a pre-existing Public Key Infrastructure (PKI).
Active Directory (AD) has long supported smart cards with its native on-prem capabilities. However, as applications have moved towards more modern authentication schemes like SAML, WS-Federation, OAUTH2, and OpenID Connect, the traditional AD has not been an ideal authentication solution without supplemental federation capabilities. Instead of investing in additional infrastructure like Active Directory Federation Services (AD FS), enterprises may instead seek to adapt their existing architecture to also use AAD for modern authentication, a cloud-based identity and access management service. It is important to emphasize that the existing AD capabilities may continue to be leveraged for legacy on-prem applications, and the discussed changes are meant only to extend the functionality. This split between authentication sources will shift the architecture to a transitional hybrid state. Please see the supplemental transition guides (below) for the next phase “target” architecture for enterprises already in this intermediate state.
AD is the source of truth for user and device identity. On-prem AD users and devices are synced with the cloud so on-prem users and some devices are now replicated in AAD. Additionally, all applications supporting modern authentication should be federated with AAD. AD may be used in some scenarios for CBA where Windows is only AD domain joined. Other scenarios may begin to leverage AAD for CBA. For example, AAD CBA may be used for applications supporting modern authentication or for Azure AD joined or hybrid joined workstations.
The user will connect the YubiKey, which contains a digital certificate with their identity information, to a computer or mobile device by plugging it in to 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 in certificate-based authentication flows to connect to AD, or Azure AD protected resources.
Access to on-prem legacy applications can be accomplished in multiple ways. Enterprises may hybrid-join Windows workstations and servers so that legacy applications can be accessed with SSO. Other enterprises may make use of Azure AD Application Proxies that can provide both access from outside of the enterprise network and can also translate between modern authentication and legacy IWA.
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.
It should be noted that wherever AD is used for authentication instead of Azure AD some capabilities will be lacking from the environment, such as identity protection and policy enforcement using Conditional Access Policy Authentication Strength.
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 |
AAD |
Azure Active Directory |
AD |
Active Directory |
AD CS |
Active Directory Certificate Services |
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 |
IWA |
Integrated Windows Authentication |
mTLS |
Mutual Transport Layer Security, a version of TLS where both the server and the |
NFC |
Near Field Communication |
OAUTH2 |
Open Authorization 2.0 |
On-Prem |
On-Premises |
OpenID Connect |
An open standard and decentralized authentication protocol promoted by the |
PIV |
Personal Identity Verification |
PKI |
Public Key Infrastructure |
RDP |
Remote Desktop Protocol |
SAML |
Security Assertion Markup Language |
SSO |
Single Sign-On |
TLS |
Transport Layer Security |
WS-Federation |
Web Services Federation |
X.509 |
A standard defining the format of public key certificates, used in many Internet |
Supported use cases
- Sign-in to Azure Active Directory protected native applications
- Sign-in to Azure Active Directory protected web applications
- 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
- Sign-in to Azure Active Directory joined Windows 10 & 11 workstations
- Sign-in to hybrid Azure Active Directory joined Windows 10 & 11 workstations
- Sign-in to hybrid Azure Active Directory joined Windows Servers
- Remote sign-in to Active Directory joined Windows 10 & 11 desktop sessions
- Remote sign-in to Active Directory joined Windows Server desktop sessions
- Remote sign-in to Azure Active Directory joined Windows 10 & 11 desktop sessions
- Remote sign-in to hybrid Azure Active Directory joined Windows 10 & 11 desktop sessions
- Remote sign-in to hybrid Azure Active Directory joined Windows Server remote desktop sessions
- Sign-on to Azure Active Directory protected Azure Virtual Desktop sessions
Where supported
Chrome, |
MS 365 |
IWA Apps (File |
Device |
Remote |
|
Windows |
Yes |
Yes |
Yes |
Yes |
Yes |
Windows |
Yes |
Yes |
Yes |
Yes |
Yes |
Windows AD |
Yes |
Yes |
Yes |
Yes |
Yes |
Windows non |
Yes |
Yes |
No |
No |
Yes *AVD Only |
MacOS |
Yes |
Yes |
No |
Yes |
Yes |
Android |
Yes (Edge w/ |
Yes |
No |
No |
No |
iPhone |
Yes (Edge w/ |
Yes |
No |
No |
No |
iPad |
Yes (Edge w/ |
Yes |
No |
No |
No |
ChromeOS |
Yes* |
No |
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
Azure AD CBA Requirements
- Azure AD Certificate Based Authentication configured
- Bring your own PKI, Certificate Authority and certificate lifecycle processes
Azure AD CBA on mobile devices with YubiKeys requirements
See the Microsoft pages for more information on YubiKey support for Azure AD CBA on iOS and Android. Please note that some scenarios will require a companion application in order to use YubiKeys with Azure AD CBA on mobile.
- Yubico Authenticator is required on iOS/iPadOS when using YubiKeys over NFC or Lightning
- Native apps require the latest version of Microsoft Authentication Library (MSAL) orMicrosoft Authenticator. Some Microsoft first-party apps are not yet leveraging the latest MSAL version and will require Microsoft Authenticator. Microsoft Authenticator is not required if and when the native app leverages the latest MSAL version.
Android (USB) |
iOS and iPadOS |
iPadOS (USB-C) |
|
Native apps |
|
|
Some native apps |
Browser- |
|
+ |
No companion apps |
** Microsoft is currently developing NFC support into their CBA on Android solution. CBA on iOS already supports NFC.
Deployment Guidance
Below are the step-by-step instructions to assist the setup and enablement of Certificate-Based Authentication for the transitional hybrid architecture with on-premises Active Directory + Azure AD. This article assumes that the on-premises AD, workstations, and PKI processes have already been setup. For review of that setup see the guidance from Phishing-Resistant Authentication for on-premises with AD and AD FS using Smart cards.
Step-by-step instructions
These are the high-level steps for enabling Azure AD CBA for your hybrid environment.
- Synchronize on-premises users to Azure AD using Azure AD Connect
- Plan your hybrid Azure AD join implementation
- Enable Azure AD Certificate-Based Authentication
- Track authentication methods activity
Supplemental Guides
- Phishing Resistant Windows Authentication On-Prem
- Enable Azure AD Certificate Based Authentication
- Azure AD Connect Support Topologies
- Azure AD Connect - Sign-in options
- Azure AD Connect - Staged rollout
- Azure AD Secure hybrid access
- Azure AD - Upgrading from ADFS
Troubleshooting
- Smart Card Basic Troubleshooting contains information on troubleshooting a variety of common issues with using smart cards.
- Troubleshoot Azure AD Certificate-Based Authentication issues
Implementation
For information on how to best utilize CBA once it is set up, the additional resources below are available. Firstly, some best practice guides 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.
Remember to enquire about our Professional Services team if hands-on or specific deployment assistance is required, and Yubico will gladly send one or more of our best people to help with your specific implementation!
Best Practices
YubiKey Lifecycle Management Best Practices with Microsoft Azure AD Passwordless
Transition Guidance
The following are some steps that will help your enterprise migrate from this transitional state to the target state hybrid architecture with on-prem and Azure AD
- Leverage hybrid Azure AD joined Windows workstations
- Leverage Azure AD Conditional Access Authentication Strengths to enforce CBA sign-ins.
- Leverage Azure AD App Proxies to allow both access from outside of the internal network perimeter and also support integration with applications protected with legacy authentication.
- Investigate additional Azure AD Identity Protection features that are available when authenticating directly to Azure AD instead of AD.