How to set up Azure Multi-Factor Authentication (MFA)

Remember the Cybersecurity Reference Architecture we referenced in our post on Windows 10 in S Mode? If we head over to the Identity & Access portion, we’ll find Multi-Factor Authentication.

What’s great about Azure MFA is that it’s particularly easy to set up. In fact, it’s already enabled in your environment. So in this post, let’s cover the settings we can configure and how to ensure our users have an optimal experience.

First, head over to the Azure portal, open Azure Active Directory, and then click Multi Factor Authentication:

Here, you can configure which users are enabled for MFA. This is poorly named (in my opinion), because it is referring to which users are enabled for per-user MFA. (For more info on per-user MFA, check out: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates). The main thing to note here are that enabling a user on this setting pane enacts a policy that forces users to use MFA every time they log in. There are some caveats (trusted IPs from the service settings won’t require MFA) but it’s worth noting that Microsoft recommends leveraging Conditional Access to require MFA instead.

In the following screenshot, note that every user account is Disabled, except one that is Enforced. What happens if we set up a Conditional Access policy for a disabled user? Let’s come back to this idea after we’ve reviewed the other settings.

If we select a user, you’ll be given options on the right:

And there’s also a few additional options under manage user settings:

If we select service settings at the top, we’ll have the following options:

The Service Settings pane gives us two important settings: Trusted IPs, and Verification Options. (App passwords refers to apps unaware of MFA, for more info: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings#considerations-about-app-passwords). The Trusted IPs range is useful for allowing users to skip MFA if they’re on your corporate network. Verifications Options let’s you select which methods will be available to your users. Once you’ve selected the appropriate option, click save.

Now, one key point to make: Azure MFA is “enabled” by Conditional Access or Azure AD Identity Protection policies requiring MFA. (Want extra proof? Here’s the docs link: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted#enable-multi-factor-authentication-with-conditional-access). MFA is available as soon as you have an Azure AD tenant – it’s just waiting for something to require it.

So what happens when we create a Conditional Access policy for a user that was set to Disabled earlier? In the Azure Portal, I select Azure AD > Security > Conditional Access > + New policy and created a policy to require MFA for myself when I open Teams.

When I open teams.microsoft.com, I’m immediately stopped by Conditional Access and prompted for more information:

When I click Next, the set up screens for MFA setup are shown:

Notice how we have Authentication phone listed but no call option:

And if we select Mobile app, we have two options:

These options will be consistent with the service settings authentication options you select earlier. I selected Authentication Phone and then provided a phone number to verify:

And with those two pages, I was able to set up and verify MFA.

But you’re probably asking – wasn’t this user disabled? Yes – that’s the confusing part. I like to think that the disabled/enabled/enforced settings aren’t referring to whether or not MFA is enabled, but rather whether a policy is enabled to require MFA for every log in.

With that in mind, the next steps would be figuring out which resources should require MFA for your organization. Then all you need to do is create conditional access policies that require MFA.

What else can we configure, though? Well – administratively, there’s another pane in the Azure portal just named Multi-Factor Authentication. Here, you can edit account lockout settings, block/unblock users, add greetings, configure OATH tokens and more. There’s a detailed guide here that covers all of these settings.

(Note – Manage MFA Server refers to the On-prem MFA server that you can additionally configure).

You can also configure Azure AD Identity Protection settings, which can require MFA for risky users (but this requires AAD P2 licensing). If you enforce the MFA Registration policy, the groups targeted will be required for register for MFA when they next log in:

And that’s it! We’ve effectively set up Azure MFA all by creating a Conditional Access policy. Within your organization, there will likely be a larger effort required – particularly around trusted IP ranges and determining which applications to secure behind MFA. But now that you’ve seen the process, you’ll be able to “enable” it just as easily!

Okay, one last thing. There’s a new end user registration portal in preview that will likely be the default soon. It merges the self-service password reset user portal and the MFA user portal. To enable it, open the Azure AD portal, click User settings, Manage user feature preview settings and then select All for “Users can use the combined security information registration experience.”

And here’s how it would look for a user to register with the new portal (after hitting the Conditional Access requirement):

That’s all! Happy deploying! 📱