Child pages
  • MFA for Azure AD and Office 365
Skip to end of metadata
Go to start of metadata

This document outlines the MFA solutions for the UW Azure AD and Office 365 ecosystem.

Background/Key Decisions

There are several key decisions underpinning progress here:

  1. Is MFA required or just enabled? IOW, do we want to allow MFA as yet another authentication possibility or require someone to use MFA?
  2. On what basis do we enable MFA? What triggers MFA? Per user, per app, per subnet, for all, or some combination of the above?

On #1, to require MFA for Azure AD & Office 365 applications we will need to use a MFA provider, most of which require Modern Authentication be used. This has an impact of breaking legacy clients, e.g. Thunderbird, Office 2010, IMAP-based, etc. Once a user must perform MFA, only email clients using Modern Authentication (ADAL) will work.

If we do not require MFA, then there are a variety of paths by which a given user might still use a password to access Office 365 applications.

Note: there may be a few additional issues for #1 based on the answer to #2 (e.g. per-app may require MFA for the MS graph) and some of the options in #2 more broadly require MFA for some set of scenarios, so there is some entanglement.

On #2, there are a variety of locations where we can trigger MFA to happen, each of which has different variables it can trigger upon and different implications. Please reference the solutions table below.

MFA Solutions Table

IDAtVariablesImpactMFA Strictly Req'dModern AuthN Strictly Req'd
1Shibboleth IdPper-user, per-relying party
  • per-user only: all Shib-based applications require MFA (except when the app is actually an AAD or ADFS RP, then if a IWA token is presented, it can be used instead)
  • per-relying party only: all ADFS relying parties require MFA, except when a IWA token is presented
  • per-user and per-relying party: all ADFS relying parties for specific users, except when a IWA token is presented
note: all of the above do not require modern authentication (needs testing)
2Azure AD (conditional access + Azure MFA)per-user, per-AAD app
  • per-user only: all AAD apps require MFA
  • per-app only: all users of that app require MFA
  • per-user and per-app: only specified users of that app require MFA

note: requires that each user have AADp1 license (covered by M365 A3 or EMS1)

note: requires that each user have two MFA options enabled–Duo and Azure MFA

3ADFS (Duo ADFS MFA stock)?all AAD-based applications require MFAYesYes
4ADFS (Duo ADFS MFA custom claims rules)group-based
  • Same as ADFS above but allows certain users to be exceptions, not required to use MFA
5Enterprise Load Balancer (for ADFS)per-subnet (maybe others?)
  • per subnet: all ADFS-based apps for those on affected subnets require MFA

note: this may poorly target customers

6Workstation/client endpointNone

note: only suitable for 'not required'

note: many client platforms have no MFA option,

note: signalling of MFA to apps is likely dependent on further work


Azure AD Authentication Architecture diagram

Azure AD governance discussion output

Notes from other universities using Duo

Specific sender's contact info not included ... contact Brian for more info.

Note 1

Yale implemented Duo campuswide for access to our VPN and Shibboleth web AuthN services a couple of years ago (before our O365 migration) so there was intense pressure for us to find a way for Duo to work with O365 when we migrated last year.


We did a bunch of testing in early 2016 to document what the experience was with Duo for O365 and compare it to the MFA which Microsoft provides with O365 (which is really Azure AD MFA).  Here are the highlights:


  • Using Duo with O365 requires running ADFS with a Duo MFA module installed in it or running Duo's local MFA server (Duo gateway?)
  • Duo MFA does not work with any mode of access that does not understand ADAL/Modern AuthN.  This means basically all non-Microsoft mail clients of any kind - iOS mail, Mac Mail, Thunderbird, Android mail, etc.
  • Furthermore, Duo MFA does not support using app passwords as a workaround for non-ADAL-enabled clients so basically all non-MS clients that want to talk to O365 are out of luck if Duo MFA is in the loop.
    • We asked Duo at the time we were doing our testing whether they were thinking of adding support for app passwords and they said it was not on their roadmap.  This was ~9 months ago so that may have changed but I don't see any references to them on a cursory check of their website. 
    • Microsoft's MFA does include support for App passwords.  They are a pain in the neck support-wise but a necessary workaround for non-MS clients.  Fortunately they don't expire so they are sort a set-and-forget option for users.
    • Lack of support for app passwords is a big weakness of Duo IMO.  Duo seems focused on protecting web-based access by humans using web browsers and not to be concerned about protecting access via apps, API's, etc.  I'll bug them about this at Ignite in September.
  • On the upside (and to help with users that resist having to have a second MFA app on their device) you can use the Duo app with Microsoft MFA if you are willing to live without push notifications.  Other 2FA methods such as SMS codes, rolling PINs, etc all work fine. 
    • To configure the Duo app for rolling PINs with Microsoft's MFA, just click on "configure client without notifications" when presented with the QR code to scan in O365 MFA setup.  Then just scan the new code with the Duo app and you're done.  This works with other apps like Google Authenticator too!


Some .edu's on this list have worked around this limitation in Duo by modifying their authentication service so that it sends login requests via browsers (e.g. OWA) through a Duo MFA challenge while access from non-browser clients bypasses Duo.  This is a clever solution and they are apparently using it with success.  We looked at this option and decided not to go this route as it has significant implementation complexity and requires maintaining an on-premise AuthN service.  A design requirement of Yale's implementation of O365 was to make sure that login access to O365 had zero dependencies on Yale-operated infrastructure.


We piloted O365 MFA with a group of users for quite a while (months) with no significant issues.  We're going to announce availability of O365 MFA on an opt-in basis as soon as we get some change management materials together.  Mandatory MFA will probably follow at some point after that, at least for VIP's and other sensitive accounts.

Note 2

Dennis, we have not yet rolled out Duo to our entire campus but we have pushed it to a number of test users. The non-Modern Authentication issue did come up and we used this Duo KB article as a template for our own ADFS claim rules to allow a specific exception group to continue to use the "legacy" clients.


If it helps anyone else, we have two groups, one is iam-duo-users and the other is iam-duo-users-legacy. These are the authentication rules we put in place to only enable Duo for iam-duo-users and allow legacy only for iam-duo-users-legacy users. We are planning on allowing an opt-in process to allow legacy access.


Rule #1 - IF member of iam-duo-users AND NOT member of iam-duo-users-legacy THEN require MFA 


exists([Type == "", Value == "S-1-5-21-sid-of-iam-duo-users"]) 
&& NOT exists([Type == "", Value == "S-1-5-21-sid-of-iam-duo-users-legacy"]) 
=> issue(Type = "", Value = ""); 

Rule #2 - IF member of iam-duo-users AND member of iam-duo-users-legacy AND request is web based THEN require MFA 


exists([Type == "", Value == "S-1-5-21-sid-of-iam-duo-users"]) 
&& exists([Type == "", Value == "S-1-5-21-sid-of-iam-duo-users-legacy"]) 
&& exists([Type == "", Value =~ "(/adfs/ls)|(/adfs/oauth2)"]) 
=> issue(Type = "", Value = ""); 


We actually tried a number of other restrictions from Microsoft KB articles and were not successful except with the above x-ms-endpoint-absolute-path version.

  • No labels