Confused by all the options for Multi-Factor Authentication on Microsoft 365? You’re not alone, it’s a common cause of security issues. But don’t worry: we tested three of the different options, so you don’t have to.
Background
The Threat
We really shouldn’t have to explain this any more, but Multi-Factor Authentication (MFA) is the best defence against account compromise, and can reduce the importance of passwords. You could even argue that MFA is more important than passwords, something we discussed in a previous blog. Whilst those in security or IT may be bored at having to evangelise MFA, unfortunately adoption is still no-where near where it should be.
Poor Numbers
As recently covered by Recorded Future, Microsoft’s first Cyber Signals paper had some miserable stats on MFA adoption:
Despite years of promotional efforts to get users to enable stronger authentication mechanisms, Microsoft said this week that only 22% of all its Azure Active Directory (AD) customers used a multi-factor authentication solution to secure their accounts last year.
Whilst we can point to a raft of defensive measures available to Microsoft 365 administrators, as ever they are complicated by a myriad of license levels and offerings, and confusing and conflicting administration panels and options.
If you’re on one on the Enterprise tiers then hopefully you also have a full-time team working on m365, who are all over Conditional Access Policies, Risky Sign-Ins and all the other more advanced protections. But if you’re on a cheaper tier, say Business Standard with Azure AD P1, you only get a subset of those protections.
And regardless of what tier you’re on, understanding the different administration options is no mean feat. So let’s run through the options.
MFA Authenticator Options
Before getting into the enforcement settings, it’s worth going over the options for the kind of authenticators you want to enable.
Possible Second Factors
Microsoft’s own guidance lists all possible MFA methods, in a somewhat odd order. Let’s help them out and come up with a proper list, from most secure to least:
- FIDO2 security key/OATH hardware token (preview)
MicrosoftAny Authenticator app/OATH software token- Windows Hello for Business
SMSVoice call
Firstly, we have to move beyond SMS or voice calls as MFA options. Whilst it doesn’t seem that common in the UK (yet?), there have been a raft of high-profile SIM swapping attacks in the US, enough that it shouldn’t be a commonly supported option.
There are accessibility arguments for both SMS and voice calls as a second factor, as some communities don’t have access to smart phones and data connections, but we can assume that’s generally not the case for most organisations, and cross them out as viable options.
Authenticator Apps
You can actually use any authenticator app with Microsoft 365, although they do push their own one. Given a free choice, we recommend Authy, as it allows for encrypted backups of all logins and works across most modern systems.
The trick is to have users pay attention to the blue text when setting up an authenticator app:
It does give you the option of another app, but many people may not spot it. As we’ll get into later, the mechanism for enforcing MFA may also have an impact on this.
Authenticator apps are a good option for most people, but there is recent evidence of advanced attackers targeting some MFA applications:
Mandiant has also observed the threat actor executing multiple authentication attempts in short succession against accounts secured with multi-factor authentication (MFA). In these cases, the threat actor had a valid username and password combination. Many MFA providers allow for users to accept a phone app push notification or to receive a phone call and press a key as a second factor. The threat actor took advantage of this and issued multiple MFA requests to the end user’s legitimate device until the user accepted the authentication, allowing the threat actor to eventually gain access to the account.
“Suspected Russian Activity Targeting Government and Business Entities Around the Globe”, Mandiant
We feel this is a good argument for encouraging authenticator apps that give you a one-time code over those that require confirmation on a prompt.
Of course, with anything to do with account security, best practice is to assume some level of attacks and compromise, and also implement monitoring. For example, those with Azure AD P2 licenses can implement risky sign-in and risky user policies. There’s also extensive logging and many expensive SIEM options, although we’ve recently set up our own dashboard in Elastic Stack:
The most secure option is a hardware security token. Whilst it does mean buying additional hardware tokens, it’s definitely the best option for users, especially for those with administrator or high-risk roles.
Hardware Security Tokens
The crucial advantage of hardware security tokens is that they need to be physically touched to complete a second-factor authentication, so they cannot be compromised over the internet. Newer devices, such as FIDO2 Yubikeys or Google Titan Keys, also require the user to enter a password, which is unique to the security key but doesn’t change for the application in use. This means they could be used for passwordless access, which is supported by Microsoft 365, but that’s a topic for another time.
Windows Hello for Business
Finally, Windows Hello for Business is an interesting option. It’s a beefed-up version of the computer Windows Hello mechanism, which authenticates to a local AD or to Azure AD. It supports fingerprints and facial recognition (which requires an infrared-capable camera), both of which are convenient for users but potentially vulnerable to local attacks. It’s not something we’ve looked at extensively; while it’s likely less secure that hardware security tokens, it is convenient for users and doesn’t require the purchase of tokens for all staff. This blog has detailed information about the enrolment process.
Implementing MFA
Typically for Microsoft 365 there are (at least?) three places where MFA settings can be applied:
- Security Defaults,
- User Management MFA Settings,
- Conditional Access Policies.
And of course, they are in conflict with each other. So let’s deal with them one at a time.
Security Defaults
The first option for enforcing MFA is by Security Defaults, which as the name implies are some default security-enforcing options:
These free security defaults allow registration and use of Azure AD Multi-Factor Authentication using only the Microsoft Authenticator app using notifications.
Set from this Azure AD admin panel, Security Defaults are an on/off choice:
They may be a good, quick option to enforce some additional security, but if you want to do anything advanced then Security Defaults are not the way to go. For example, they are somewhat contrary to the CIS security benchmarks, which explicitly recommends disabling them.
They also limit the possible authenticator options compared to another enforcement option Conditional Access, which we’ll cover later on. This table from the Security Defaults page provides a good summary:
If you disable Security Defaults, you have two options left for MFA.
User Management MFA Settings
The second option is to use this fairly hard to find configuration panel, which also happens to have MFA disabled by default:
There’s a fairly unobvious second tab to that page for some general settings, including which authenticators are allowed and session control:
If, as we first did, you’re surprised to see all your users listed as having MFA disabled, don’t panic. As stated on the Security Defaults page:
If your organization is a previous user of per-user based Azure AD Multi-Factor Authentication, don’t be alarmed to not see users in an Enabled or Enforced status if you look at the Multi-Factor Auth status page. Disabled is the appropriate status for users who are using security defaults or Conditional Access based Azure AD Multi-Factor Authentication.
That’s a very important detail, which would have been nice to have on the page shown above as a note.
If you don’t have an Azure AD P1 or P2 license, either directly or from another Microsoft 365 E-level package, then this interface is probably your best option. But if you do have P1/P2, you’re better off making good use of the license costs and implementing Conditional Access Policies, which are our third and final option.
Conditional Access Policies
If you have Azure AD P1 or P2 (directly or as part of an Microsoft 365 E3 or E5 subscription) you can also make use of Conditional Access Policies (CAP).
CAP are probably worth its own blog, but the quick guide for MFA is to have a rule that applies to all typical user accounts, for all cloud apps, client apps and locations, and grants access but requires MFA:
We also use it to enforce other security rules, for example:
- Blocking some countries from any access.
- Forcing MFA for access from other countries.
- Blocking access to Teams and Sharepoint for shared and non-personal accounts.
- Blocking legacy applications
When applying CAP, a good first option is to setup the rule in report-only mode, to test it’s working as intended:
Another useful tool is the Sign-in logs option on the conditional access page, which shows for each sign-in event what policies were applied, for what result:
Finally, to set what authenticators are allowed, this Azure AD admin panel replicates the options on the MFA page:
Obligatory Caveat
This blog was accurate in April 2022. No doubt, one or all of these settings may change in the future, but we’ll endeavour to make updates.
Follow-Up
We help our customers will all manner of security incidents and investigations, including with Microsoft 365. If you want to improve your security, we also complete security audits and security hardened configuration of Microsoft 365 and Google Workspace tenants. Read more on our services page.
Related Posts
