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


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.

Phishing-Resistant_Authentication_for_transitional_hybrid_environments_with_AD_and_Azure_AD_using_Smart_cards_1.png

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
client authenticate each other

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

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
protocols, PKI, offline applications and electronic signatures.

 

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,
Edge, Safari
browsers

MS 365
native
apps

IWA Apps (File
Sharing,
Databases, etc)

Device
sign in

Remote
Desktop and
Azure Virtual
Desktop

Windows
Azure AD
joined

Yes

Yes

Yes

Yes

Yes

Windows
Hybrid Azure
AD joined

Yes

Yes

Yes

Yes

Yes

Windows AD
joined

Yes

Yes

Yes

Yes

Yes
*Remote Desktop
Only

Windows non
domain joined

Yes

Yes

No

No

Yes  *AVD Only

MacOS

Yes

Yes

No

Yes

Yes
*Remote Desktop
Only

Android

Yes (Edge w/
profiles only)

Yes

No

No

No

iPhone

Yes (Edge w/
profiles or
Safari)

Yes

No

No

No

iPad

Yes (Edge w/
profiles or
Safari)

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 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
(Lightning or NFC)

iPadOS (USB-C)

Native apps

Phishing-Resistant_Authentication_for_cloud_native_environments_with_Azure_AD_using_Smart_cards_2.png
or latest
MSAL

Phishing-Resistant_Authentication_for_cloud_native_environments_with_Azure_AD_using_Smart_cards_2.png or latest MSAL
+
Phishing-Resistant_Authentication_for_cloud_native_environments_with_Azure_AD_using_Smart_cards_3.png

Some native apps
are supported.

Browser-
based web
apps (Safari or
Edge with
profiles)

Phishing-Resistant_Authentication_for_cloud_native_environments_with_Azure_AD_using_Smart_cards_2.png
or latest
MSAL

Phishing-Resistant_Authentication_for_cloud_native_environments_with_Azure_AD_using_Smart_cards_2.png or latest MSAL

+
Phishing-Resistant_Authentication_for_cloud_native_environments_with_Azure_AD_using_Smart_cards_3.png

No companion apps
required

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

  1. Synchronize on-premises users to Azure AD using Azure AD Connect
  2. Plan your hybrid Azure AD join implementation
  3. Enable Azure AD Certificate-Based Authentication
  4. Track authentication methods activity

 

Supplemental Guides

 

Troubleshooting

 

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.

 

Common Questions

Yubico FAQ