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 only or cloud only architecture is considered out of scope for the purposes of this article, and the focus will instead be on hybrid (i.e. 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. Enterprises may additionally have Active Directory Federation Services (AD FS) deployed, however this component does not have a significant impact on this architecture and thus will not be referenced in this guide. It is also important to note that other forms of authentication are considered out of scope for the purposes of this guide, and the focus will instead be on FIDO2 only. Other authentication methods that support FIDO2 onboarding and/or recovery will be mentioned, but it should be made clear that those methods will not be the focus of this guide. A description of FIDO2 and related terminology can be found here.
Figure 1. Hybrid architecture with on-prem AD and AAD
Figure 1. (above) shows the relationships between the major components in a hybrid environment that uses FIDO2 security keys for authentication and leverages an AAD tenant. AAD FIDO2 passwordless is used for authentication to Windows workstations, web applications and native applications.
The AAD FIDO2 passwordless solution supports FIDO2 security keys as a phishing-resistant standards-based authentication method, enabling users to sign in to resources without a username or password (i.e. passwordless).
Active Directory has long been the main authentication source for enterprises. 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 that supports the suite of modern authentication schemes. 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. On-prem AD users and devices are synced with the cloud so on-prem users and devices are now replicated in AAD. All on-prem and cloud-native applications supporting modern authentication should be federated with AAD.
On-prem applications that don't support modern authentication can be accessed from either hybrid joined workstations or via an Azure AD Application Proxy. Azure AD Application Proxies can mediate between modern authentication and legacy authentication methods and also can be used to securely expose internal services to the public internet.
Different device types and device management states support different scenarios with FIDO2 security keys. Non-joined, AD domain joined, AAD joined and hybrid joined workstations all support FIDO2 security sign-in for different scenarios. Windows, macOS, and Linux also have varying support for when FIDO2 security keys can be used. See the "Supported use cases" and "Where supported" sections below for more details.
Registration of FIDO2 security keys
In the depicted scenario, the user is responsible for registration of their own FIDO2 security keys (i.e. self-registration). Registration involves the user first signing into My Account and navigating to the security info portal with an alternate authentication method that satisfies AAD's multi-factor authentication requirements. Enterprises may opt to make these MFA requirements stricter to include only those that are phishing-resistant, but sign-in with at least basic multi-factor authentication is a minimum requirement before a user is able to register a new FIDO2 security key. For example, most organizations will either use Certificate-based authentication (CBA), Temporary Access Pass (TAP) or Username + Password + One-time Password (OTP) to meet those MFA requirements.
Sign-in with FIDO2 security keys
Users may leverage FIDO2 security keys to sign-in to many different systems and on many different platforms. Authentication is centralized with AAD and users' registered security keys will work across a wide range of workstation and application sign-in scenarios, including sign-in to their Windows AAD joined or hybrid-joined workstations for both online and offline scenarios. Once signed in to their Windows workstations, users may sign-in to applications including web applications, first party Microsoft productivity applications, or other AAD protected custom and third party apps. Other platforms like macOS, Google Chromebooks and Linux also support sign-in to web applications.
Policy driven enforcement
Enterprises may enforce the use of FIDO2 security keys using Conditional Access (CA) with Authentication Strengths (preview). This feature allows enterprises to require FIDO2 security keys on all devices and platforms that support it while also having flexibility to allow alternate authentication methods or simply block access for other scenarios that don't support FIDO2 authentication. These policies are an important tool that allow enterprises to support initial registration of FIDO2 credentials with alternate methods while preventing those non-FIDO2 methods from being used in any other scenario.
Section Supported use-cases of this document below, will provide additional context for how FIDO2 is used as seen in Figure 1. (above).
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 FS | Active Directory Federation Services |
CA | Conditional Access |
FIDO2 | Fast IDentity Online version 2 |
HRMS | Human Resources Management System |
NFC | Near Field Communication |
OTP | One-Time Password |
RP | Relying Party |
TAP | Temporary Access Pass |
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 Azure Active Directory joined Windows 10 & 11 workstations
- Sign-in to hybrid Azure Active Directory joined Windows 10 & 11 workstations
- 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
- Remote sign-in to Azure Active Directory joined AVD Session Hosts
- Remote sign-in to Hybrid Azure Active Directory joined AVD Session Hosts
Where supported
This matrix represents where FIDO2 sign-in is supported for the target-state architecture depicted above.
|
Chrome, |
MS 365 |
IWA Apps (File |
Device |
Remote |
Windows Azure AD joined |
Yes |
Yes |
No |
Yes |
Yes |
Windows Hybrid Azure AD joined |
Yes |
Yes |
Yes |
Yes |
Yes |
Windows AD joined |
Yes |
Yes |
No |
No |
Yes |
Windows non domain joined |
Yes |
Yes |
No |
No |
Yes |
MacOS |
Yes |
No |
No |
No |
Yes *AVD Only |
Android |
No |
No |
No |
No |
No |
iPhone |
Yes |
No |
No |
No |
No |
iPad |
Yes |
No |
No |
No |
No |
ChromeOS |
Yes |
No |
No |
No |
Yes *AVD Only |
Prerequisites and Requirements
Azure AD FIDO2 Passwordless Requirements
- Office 365 or Azure AD free tier or greater.
- Supported FIDO2 security keys
- Windows 10 v2004+ for hybrid-joined Windows sign-in support
- Supported browser
Deployment Guidance
Below are the step-by-step instructions to assist the setup and deployment of Azure AD FIDO2 Passwordless, 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 FIDO2 security keys. Please see the Supplemental Guides for more detailed information. Note that attestation information is only collected during initial registration, so if there is any possibility that attestation information will be required in the future for compliance reasons, it’s highly recommended that attestation is enforced before any wide rollout of security keys.
- Sign-in to the Azure portal
- Enable FIDO2 security keys as an Authentication Method
- Enable self-service setup
- Enforce attestation (Recommended)
- Enforce key restrictions (Optional)
- Configure an Azure AD kerberos server object in on-prem AD (optional)
Supplemental Guides
- YubiKeys for Microsoft Azure AD Passwordless Sign In Guide
- Microsoft and Yubico Part 1 - Enterprise Strong Authentication with YubiKey
- Microsoft and Yubico Part 2 - Enterprise Strong Authentication for Cloud Native Organizations
- Microsoft and Yubico Part 3 - Enterprise Strong Authentication for On-premises and Cloud Organizations
- Microsoft and Yubico Part 4 - Enterprise Strong Authentication Recommended Action Items
- Enable passwordless security key sign-in to Windows 10 devices with Azure Active Directory
- Microsoft - different kinds of accounts (365, Azure, etc.), and how to use YubiKeys with them
- User Guides:
Troubleshooting
Implementation
For information on how to best utilize FIDO2 security keys once it is enabled, 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