Phishing-Resistant Authentication for Cloud-native environments with Azure AD using Smart cards

Overview and Introduction

The following guide describes how to set up Azure Active Directory (AAD) Certificate-Based Authentication (CBA) for a cloud native environment. A brief description of an environment using CBA 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 authentication are considered out of scope for the purposes of this article, and the focus will instead be on CBA only.

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

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 cloud native environments with Azure AD using Smart cards

Figure 1. (above) shows the relationships between the major components in a cloud native environment that uses AAD as the only identity provider, and smart cards for authentication. While both user information and lifecycle may be managed by another source such as a Human Resources Management System (HRMS) system using System for Cross-domain Identity Management (SCIM), AAD is the only source of identity in this cloud native environment.

The user will connect their YubiKey, which contains a digital certificate with their identity information, using USB, Lightning or wirelessly over NFC. Once the YubiKey is coupled and unlocked with a PIN, it can then be used in CBA flows to connect to AAD protected resources. Once AAD has been pre-configured with a trusted smart card issuer certificate authority (CA) chain, it is able to check the Certificate Revocation List(s) (CRLs) to ensure certificates are still valid. The PKI lifecycle processes govern the circumstances around issuance, renewal and provisioning of the digital certificate contained on the Yubikey, as well as tracking certificate revocation and publishing new CRLs in a timely manner.

Microsoft describes 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).

Since AAD CBA allows customers to bring their own Public-Key Infrastructure (PKI) to their AAD tenant to support X.509 certificate-based sign-on to AAD protected workstations and applications, it should be stated that one of the primary benefits is reduced implementation friction. The AAD CBA authentication method is now generally available for all AAD customers and works with all YubiKey models that support Personal Identity Verification (PIV). This CBA capability is natively supported in AAD without the need for external federation to other providers like Active Directory Federation Services (AD FS). AAD CBA provides enterprises with strong phishing-resistant authentication that works across most platforms, devices and applications and can also seamlessly integrate with other AAD features like Conditional Access Policy (CAP) Authentication Strengths. Leveraging Conditional Access Policies with Authentication Strengths, allows an enterprise to mandate phishing-resistant authentication methods such as AAD CBA.

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 Azure Active Directory joined Windows 10 & 11 workstations
• Remote sign-in to Azure Active Directory joined Windows 10 & 11 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

• Office 365 or Azure AD free tier or greater.
• 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) or Microsoft 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 deployment of AAD CBA, 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.

Step-by-step instructions

These are the high-level steps for enabling AAD CBA. Please see the Supplemental Guides for more detailed information.

1. Sign-in to the Azure portal
2. Upload the Certificate Authority public certificate chain
3. Enable CBA as an Authentication Method
4. Configure Authentication Binding Policy
5. Configure Username Binding Policy

Supplemental Guides

• Enable Azure AD Certificate-Based Authentication
• Azure Authentication Guides

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

Common Questions

Yubico FAQ

Prevent phishing with Azure AD and YubiKeys