Phishing-Resistant Authentication for target state hybrid environments with AD and Azure AD using Smart cards

Overview and Introduction

The following guide contains information to help achieve a highly functional hybrid architecture consisting of an on-premises (on-prem) Active Directory (AD) and 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 similar hybrid deployments that may have been used before arriving at this target state hybrid architecture see transitional state hybrid architecture with on-premises Active Directory and Azure AD and 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 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. 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. Phishing-Resistant Authentication for target state hybrid environments with AD and Azure AD using Smart cards

To best understand this architecture in Figure 1, it may be helpful to first understand the transitional state hybrid architecture with AD and transitional state hybrid architecture with AD and AD FS that enterprises may have had before the state shown in Figure 1. This hybrid architecture in Figure 1 is not considered transitional because all the authentication is now occurring in the cloud with Azure AD. This is different from the transitional hybrid architectures mentioned above that split authentication between on-premises and the cloud.

Figure 1 shows the relationships between the major components in a target state hybrid environment that uses smart cards for authentication and leverages an Azure AD tenant. AAD CBA is used for authentication to Windows workstations, web applications and native applications.

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 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 additional 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 use Azure AD 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. However AAD is the main authentication point for users and devices.

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 devices are now replicated in AAD. Additionally, all applications supporting modern authentication should be federated with AAD.

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 on-premises 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.

Some of the acronyms and key terms used throughout the guide are defined in the glossary table below, to help provide clarity and context.

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 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

* May require 3rd party extension

Prerequisites and Requirements

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.

** 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 target state hybrid architecture with on-premises Active Directory + Azure AD. This article assumes that the setup has been completed from: Transitional state hybrid architecture with on-premises Active Directory + Azure AD

Step-by-step instructions

These are the high-level steps for fully enabling Azure AD CBA for your hybrid environment.

1. Complete synchronization and ensure all the user populations from AD are in scope to authenticate directly to Azure AD using Azure AD Connect and optionally staged rollout.
2. Hybrid join all the workstations that will require on-premises access or optionally enable Azure AD application proxies for access.
3. Enable Azure AD CBA for all user populations.
4. Require Azure AD CBA for all users by enabling Azure AD Conditional Access Authentication Strengths
5. Track authentication methods activity in the tenant with activity reports.

Supplemental Guides

• Phishing Resistant Windows Authentication On-Prem
• Enable Azure AD Certificate Based Authentication
• Transitional state hybrid architecture with on-premises Active Directory + Azure AD
• Azure Authentication Guides
• 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 AAD 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

Common Questions

Yubico FAQ