Child pages
  • 2FA options analysis for O365/AAD
Skip to end of metadata
Go to start of metadata

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.

AttributeModel 1a – No Federation – AAD w/ hashes and Duo 2FAModel 1b – No Federation – AAD w/ hashes and Azure 2FAModel 3c – Federate with IdPModel 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-fold1, 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-fold1, 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-fold1, which would drive up telephony charges to about $434K/year
  • Telephony costs could be reduced by using "remember me" functionality

1AAD 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.

2 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

  • No labels