Re: MFA/2FA Implementation Questions

[Blake M Bourgeois <bbour53 () LSU EDU>]

Good morning, Jim-

I don't have any input as far as exceptions, as we are not allowing exceptions where licensing allows the use of MFA. I 
can provide feedback related to implementation, caveats, and workarounds.

I do not have a breakdown of makes and models but I can say that as of December or so, the Gmail application now does 
modern auth. There are other third party applications, like BlueMail, and I believe Nine, which work with Modern 
Authentication. Like you said, due to device ages and the massive amount of different makes and models it's difficult 
to do any real, certifiable list. There is always OWA in the browser for devices too old to install any app that does 
modern auth (like forr the unfortunate few using Windows Phones) From a user experience perspective, especially when it 
comes to remembering and recertifying MFA, the Outlook app is truly the best experience.

There is still a problem with iOS native applications that can do modern auth but act strangely when the MFA token 
expires. The application doesn't understand the difference between needing to re-verify MFA and an incorrect password, 
resulting in inconsistent messaging and multiple pop ups. For these cases the Outlook app is another good suggestion-I 
would worry even with the catalog of Android devices with different OEM apps that do modern auth natively, you could 
run into these types of inconsistent/experience breaking issues.

Thunderbird still can't do MFA on desktop though it should be "coming soon." Evolution is the only Linux thick-client 
that is MFA-capable at the moment, to my knowledge. OS X users can use native mail or Outlook.

If you're not already, I would recommend ensuring you're using the "converged" experience for MFA and SSPR, even if 
you're not using SSPR yet. The interface is much, much friendlier and easy to use. It also opens you up to use 
passwordless authentication through the Authenticator app which is awesome and could be a big draw to get users to 
adopt. SSPR configure allows the enforcement of having multiple methods configured.

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-registration-mfa-sspr-combined

If you're going the Azure MFA route please make sure you've already disabled access to legacy protocols on the accounts 
directly or through conditional access policies otherwise MFA is worthless.

Three things we learned since beginning Azure MFA rollout eight months ago:

  1.  Users inexplicably, often, submit Azure MFA fraud reports. If you have the default fraud call setting (0#) expect 
a lot of false positives. By extension, if you have MFA configured to block user after a fraud report 
(https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings#configuration-options), 
be aware only Azure Global Administrators can lift that block today. You need at least the Authentication Administrator 
role to reset or require registration for MFA.


  1.  More so that you'd ever imagine, users lose access to their enrolled methods. Either because they get new phones 
and, shockingly, new phone numbers or because they never set up alternate methods, and do something like remove the 
Microsoft Authenticator app to "free up space." You will need a process in place to ensure you can reset MFA 
enrollments for users/require re-registration.



  1.  The phone call is by far the most problematic method and should be avoided, despite the fact a majority of your 
users will select it as their one and only verification method. Users block the number and it goes straight to 
voicemail, privacy or do not disturb settings may automatically reject the call, users who are travelling get really 
weird or inconsistent results across international carriers, the touch tone may not be accepted, etc.

A few finishing thoughts...
On both iOS and Android, the Microsoft authenticator app can back up enrollments to the cloud and restore enrollments 
on new devices, if you have the appetite to suggest that.
Applications like Authy are also useful, as they can be restored across devices (but if you lose access to the phone 
number, all bets are off).
Authy offers a desktop version. There is also an application called authenticator.cc for Firefox and Chrome. It's a 
last-ditch offer for the three users you'll encounter in your environment with no access to a phone in any way shape or 
form.
QR codes can be saved and used to reconfigure an application later, if switching devices.
You can enroll 5 code generator apps (though each QR code can be used indefinitely across multiple code 
generators/devices without incrementing this) and 5 Microsoft Authenticator apps, useful for users that have a tablet 
or something.
Having a primary and secondary phone (landline? Google voice? etc) is good practice.
If you populate Office phone numbers and have them available as an MFA method users will be tempted to select it, but 
make sure they're aware of when MFA comes into play that they will likely not be in their office to answer that call.
Accessing the MFA portal always requires MFA verification, regardless of any IP addresses you mark as trusted.
Azure AD logs will provide valuable troubleshooting information regarding failed MFA sign ins but the log format and 
available fields change every couple of months resulting in you needing to relearn what new log fields mean or what 
views need to be considered. Filters you rely on today may not be consistently available next week.


Blake Bourgeois, GCED, CISSP
Security Analyst 3, IT Security and Policy
Information Technology Services
Louisiana State University
Office 225-578-1218
bbour53 () lsu edu<mailto:bbour53 () lsu edu>

From: The EDUCAUSE Security Community Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU> On Behalf Of Pardonek, Jim
Sent: Tuesday, February 4, 2020 9:26 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] MFA/2FA Implementation Questions

Hi All,

Our MFA project has hit a few snags and our senior leadership is asking us to gather more information from other 
schools to identify and potential issues.

Rather than Duo, the university opted for Microsoft and although mostly smooth so far, we still have some nagging 
problems that keep coming up.

One that has come up as of late is modern auth support for android email.  Seems like 3 months ago, the answer for 
anyone with an android was install the Outlook client.  What we have been finding is that Samsung phones, for example, 
S7 or later that have a minimum email client version of 6.1.01.0 work with modern auth.  Given the rabbit hole that 
androids can make. We are now being asked to test as many makes, models and versions of android phone that we can get 
our hands on.  If anyone has done this research, we would appreciate any insight.

I've asked this on a previous post but got no responses but thought I'd ask again regarding exception groups.  Our 
current stance is to except Board members, Council of Regents and alumni. We would be interested in seeing what other 
schools are doing.

Lastly if you would be kind enough to share any pitfalls, constraints and roadblock as well as implementation 
recommendations, we would greatly appreciate it.

Thanks in advance.


James Pardonek, MS, CISSP, CEH, GSNA
Associate Director
Chief Information Security Officer
Loyola University Chicago
1032 W. Sheridan Road | Chicago, IL  60660

*: (773) 508-6086

Loyola University Chicago will never ask you for your username or password.
For the latest information security news at Loyola, please follow us online,
Twitter: @LUCUISO
Facebook: 
https://www.facebook.com/lucuiso/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2Flucuiso%2F&data=02%7C01%7Cbbour53%40LSU.EDU%7C7bdfea0b52ff46a2c87308d7a986884a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C637164267590782786&sdata=dqS%2BJAXpWxwXypfN0C%2BxiUaTfO%2BzHpSOxzKv1bUHIHo%3D&reserved=0>
Our Blog http://blogs.luc.edu/uiso/


**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity&data=02%7C01%7Cbbour53%40LSU.EDU%7C7bdfea0b52ff46a2c87308d7a986884a%7C2d4dad3f50ae47d983a09ae2b1f466f8%7C0%7C0%7C637164267590792782&sdata=7T%2F8Oyhm8i%2Fp1947xEP7zoGPchEQG7R0WI04FIefSW8%3D&reserved=0>

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community