Phishing-Resistant Authentication for transitional hybrid environments with AD, AD FS 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 Federation Services (AD FS) 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 FS solution, but also that an AAD tenant is available. Finally, for deployments that focus on hybrid deployments with only on-premises AD see the transitional state hybrid architecture with on-premises Active Directory 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 other usual 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-prem AD FS and AAD

Figure 1 shows the relationships between the major components in a transitional hybrid environment that uses smart cards for authentication and leverages an Azure AD tenant federated with on-premises AD FS. Yubico is considering the architecture in Figure 1 as transitional because the authentication is split between the cloud and on-premises. 

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.

Active Directory Federation Service (AD FS) enables federated identity and access management by securely sharing digital identity and entitlements rights across security and enterprise boundaries (including external parties and networks). AD FS extends the ability to use single sign-on (SSO) functionality that is available within a single enterprise boundary to internet-facing applications to enable customers, partners and suppliers a streamlined user experience while accessing the web-based applications of an enterprise.

In Figure 1, 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, applications supporting modern authentication are federated with AAD. Azure AD has been configured and federated to an on-prem AD FS instance to authenticate users with modern authentication using CBA against the enterprise PKI. 

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 while Azure AD is used in Figure 1, even though CBA is supported by AD and AD FS however other capabilities typically available in the cloud 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.

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

* 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

A complete Active Directory Federation Services deployment with internal AD FS servers and (optionally) externally available Web Application Proxy servers.

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. The linked articles are written describing support for Azure AD CBA; however the same support provides certificate-based authentication using AD FS with a federated Azure AD tenant. 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 CBA for the transitional state hybrid architecture with on-prem AD FS and Azure AD. This article assumes that the on-prem AD, workstations AD FS, and PKI processes have already been set up. 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. Federate the Azure AD tenant with AD FS
4. Identify AD FS federated applications that can migrate to federation with Azure AD
5. Migrate AD FS federated apps to federation with Azure AD
   
   

Supplemental Guides

• Phishing Resistant Windows Authentication On-Prem
• Enable Azure AD Certificate Based Authentication
• Azure Authentication Guides
• Azure AD Connect Support Topologies
• Azure AD Connect - Sign-in options
• Azure AD Secure hybrid access

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 strategic features like Staged Rollout that will allow specific groups to migrate to Azure AD for authentication instead of AD FS.
• Leverage Azure AD Conditional Access Authentication Strengths to enforce CBA sign-ins.
• Leverage Azure AD App Proxies to migrate other AD FS features like the AD FS Web Application Proxy. This allows both access from outside of the internal network perimeter and supports integration with apps protected with legacy authentication.
• Investigate additional Azure AD Identity Protection features that are available when authenticating directly to Azure AD instead of AD FS.

Common Questions

Yubico FAQ