Introduction

A one-month project was conducted to determine the best options to provide 2FA to Azure Active Directory (AAD) apps and to Office 365 apps specifically. An analysis of primary authentication pathways and possible 2FA integration points discovered fourteen solution architectures. Additional analysis, considering multiple factors, determined that ten of the options were not a good fit, leaving four solutions under consideration.

This document presents these four finalists and provides a matrix of key differentiation criteria. The intent is to provide an aid to decision makers.

Best Options

Figure 1. High-level architecture for O365/AAD/2FA finalist solutions. Columns of white boxes connected by arrows illustrate dependencies and protocols for primary authentication. Orange and blue boxes indicate where 2FA options would be deployed. The four finalist solutions are referred to as 1a, 1b, 3c, and 5e and are recommended as the best options from an original list of fourteen (see AAD apps and 2FA.png).

Table 1. Comparison of key attributes for O365/AAD/2FA finalist solutions. See Figure. 1 for a depiction of each option.

Attribute	Model 1a – No Federation – AAD w/ hashes and Duo 2FA	Model 1b – No Federation – AAD w/ hashes and Azure 2FA	Model 3c – Federate with IdP	Model 5e – ADFS (current model)
Architectural simplicity	Fewest authentication components; no proxies Fewest points of failure Most new provisioning components; sync password hashes Fewer new 2FA components; Duo 2FA integration ADFS and IdP still present for other applications	Fewest authentication components; no proxies Fewest points of failure Most new provisioning components; sync password hashes Most new 2FA components; Microsoft Authenticator, enrollment components, transaction logs ADFS and IdP still present for other applications	More authentication components; one proxy between AAD applications and authentication systems More points of failure No new provisioning components No new 2FA components ADFS and IdP still present for other applications	Most authentication components; two proxies between AAD applications and authentication systems Most points of failure No new provisioning components No new 2FA components
Protocols for primary (password) authentication	"Modern" and Web clients OIDC and OAuth "Legacy" clients Integrated Windows Authentication	"Modern" and Web clients OIDC and OAuth "Legacy" clients Integrated Windows Authentication	"Modern" and Web clients OIDC and OAuth SAML2 browser profile "Legacy" clients SAML ECP	"Modern" and Web clients OIDC and OAuth WS-Trust and WS-Federation SAML2 browser profile "Legacy" clients Not supported
2FA triggering	"Modern" and Web clients AAD conditional access rule triggers Duo 2FA at AAD "Legacy" clients 2FA not supported	"Modern" and Web clients AAD conditional access rule triggers Azure 2FA at AAD "Legacy" clients 2FA not supported	"Modern" and Web clients AAD conditional access rule triggers AAD to set authnContextClass when requesting 2FA from IdP IdP enforces 2FA based on requested authnContextClass (translation required) and authentication policy control "Legacy" clients Maybe? Append 2FA passcode to password and IdP extracts two elements to verify? IdP would have to submit username/code to 2FA API rather than use Duo iframe.	"Modern" and Web clients AAD conditional access rule triggers AAD to send 2FA signal to ADFS ADFS custom claims rule triggers ADFS to use authnContextClass when requesting 2FA from IdP IdP enforces 2FA based on requested authnContextClass (translation required) and authentication policy control "Legacy" clients Not supported
Authentication policy control	AAD conditional access rules can apply policy based on application, application type, user, group, device, device type, network, and real-time risk score AAD conditional access can detect modern and legacy clients and can enforce 2FA for modern clients only Duo provides additional policy controls for 2FA	AAD conditional access rules can apply policy based on application, application type, user, group, device, device type, network, and real-time risk score AAD conditional access can detect modern and legacy clients and can enforce 2FA for modern clients only	IdP can directly apply policy based on user or group IdP can't directly apply policy based on application; AAD is the only "application" visible to IdP IdP can't currently apply policy based on device, device type, network, or real-time risk score The IdP can enforce 2FA policy based on authnContextClass class sent from AAD Duo provides additional policy controls for 2FA	IdP can directly apply policy based on user or group IdP can't directly apply policy based on application; ADFS is the only "application" visible to IdP IdP can't currently apply policy based on target device, device type, network, or real-time risk score The IdP can enforce 2FA policy based on authnContextClass class sent from ADFS Duo provides additional policy controls for 2FA
User Experience	Primary authentication Users must use two main web authentication interfaces among UW-IT supported applications (AAD and IdP) Second factor "Modern" and Web clients continue to use Duo for 2FA No 2FA support for "Legacy" clients	Primary authentication Users must use two main web authentication interfaces among UW-IT supported applications (AAD and IdP) Second factor "Modern" and Web clients use Azure 2FA To use push notification with Azure 2FA, users must install Microsoft Authenticator and enroll their 2FA device It should be possible to use the Duo mobile app or Microsoft Authenticator for TOTP passcodes with Azure 2FA Users must manage their 2FA devices in two different systems (AAD and Duo) No 2FA support for "Legacy" clients	Primary authentication IdP retains role as primary web authentication interface among UW-IT supported applications Second factor "Modern" and Web clients continue to use Duo for 2FA SAML ECP experience for "Legacy" clients, if this is possible, would require users to append a Duo device code or a 2FA passcode to their password.	Primary authentication IdP retains role as primary web authentication interface among UW-IT supported applications Second factor "Modern" and Web clients continue to use Duo for 2FA No 2FA support for "Legacy" clients
Password Security	Requires syncing password hashes to AAD, which is new There are good controls to manage the security risk Syncing hashes enables benefits from AAD Identity Protection (e.g. detect compromised accounts) Requires users to recognize new secure location to enter passwords	Requires syncing password hashes to AAD, which is new There are good controls to manage the security risk Syncing hashes enables benefits from AAD Identity Protection (e.g. detect compromised accounts) Requires users to recognize new secure location to enter passwords	Syncing password hashes not required If the benefits of AAD Identity Protection are desired, that can also be done independently from this option Use of ECP for legacy clients, if possible, exposes user passwords to proxy	Syncing password hashes not required If the benefits of AAD Identity Protection are desired, that can also be done independently from this option
Available 2FA factors	Supports all Duo 2FA options Push notifications TOTP passcodes HOTP hardware tokens U2F tokens Phone call back Bypass codes SMS (disabled in UW Duo tenant)	Supports all Azure 2FA options Push notifications TOTP passcodes HOTP hardware tokens (coming) Phone call back SMS	Supports all Duo 2FA options Push notifications TOTP passcodes HOTP hardware tokens U2F tokens Phone call back Bypass codes SMS (disabled in UW Duo tenant)	Supports all Duo 2FA options Push notifications TOTP passcodes HOTP hardware tokens U2F tokens Phone call back Bypass codes SMS (disabled in UW Duo tenant)
Windows Hello for Business	Not compatible	Compatible Provides stronger forms of authentication for workstation sign in	Not compatible	Not compatible
Non-authentication impacts to AAD environment	Supports AAD device join AAD device join may be key to future device management strategy	Supports AAD device join AAD device join may be key to future device management strategy	SAML federation prevents AAD device join (dependence on WS-Trust) Azure SQL (and an undocumented list of some other Azure services) require WS-Trust and could not function with this option	Supports AAD device join AAD device join may be key to future device management strategy
Product support	Technology stack provided by Microsoft AAD and Duo Two support providers Potentially longer times to diagnosis and repair with two parties	Full technology stack is provided by Microsoft AAD Only one support provider In theory, the simplest to support, with shorter time to diagnosis and repair	Technology stack provided by Microsoft AAD, Duo, and UW IdP Three support providers Potentially longer times to diagnosis and repair with three parties	Technology stack provided by Microsoft AAD, Microsoft ADFS, Duo, and UW IdP Three support providers Potentially longer times to diagnosis and repair with three parties
Transition impacts on AAD	Changing the AAD federation model takes 1-4 hrs Potential for client impact, expected to be minimal	Changing the AAD federation model takes 1-4 hrs Potential for client impact, expected to be minimal	Changing the AAD federation model takes 1-4 hrs Potential for client impact, expected to be minimal	This is the current AAD federation model, no change is required
Licenses/Cost	Using the Duo integration in AAD requires a Microsoft AAD P1 license. This is covered by a M365 A3 license, which students and employees have, but other populations would need to purchase Requires no additional Duo licenses for existing user base Adding new populations that require a Duo "hospital" license would incur a large increase in annual Duo license costs Using Duo for O365/AAD would increase Duo utilization 23-fold¹, which would drive up telephony charges to about $434K/year Telephony costs could be reduced by using "remember me" functionality	Requires no additional licenses or costs for existing user base	Requires no additional Duo licenses for existing user base Adding new populations that require a Duo "hospital" license would incur a large increase in annual Duo license costs Using Duo for O365/AAD would increase Duo utilization 23-fold¹, which would drive up telephony charges to about $434K/year Telephony costs could be reduced by using "remember me" functionality	Requires no additional Duo licenses for existing user base Adding new populations that require a Duo "hospital" license would incur a large increase in annual Duo license costs Using Duo for O365/AAD would increase Duo utilization 23-fold¹, which would drive up telephony charges to about $434K/year Telephony costs could be reduced by using "remember me" functionality

¹AAD auths/month = 8M currently; Duo auths/month = 350K currently; current telephony costs are about $19K/year. For this calculation, it is assumed that the current distribution of Duo 2FA device type use would also apply to the AAD use case.

² We have 98K M365 A3 (paid) licenses for employees and sufficient equivalent (unpaid) licenses for students. Populations which need this capability would need to purchase a M365 A3 license at a cost of $37.74/user/year

Child pages

2FA options analysis for O365/AAD

Introduction

Best Options