Before Microsoft suffers another failure with their Azure multi-factor authentication (MFA) product, take these steps to ensure continued administrative access.

You may have seen in the recent tech news or unfortunately been affected by Microsoft's recent failures with their Azure Active Directory (AD) multi-factor authentication (MFA) service. Before this happens again (and it might), you need to protect both your administrative and user Azure ID identities.

Today I will teach you how to preserve emergency admin access to your Azure AD tenant and subscription resources. In a subsequent article, I will cover how to protect end-user Azure AD user accounts. Let's get to it!

First, stop using the old portal to assign MFA policy ^

The traditional path in Azure Resource Manager to configure MFA policies for your admins and users involves logging into the Azure portal, browsing to your Azure AD tenant, navigating to the Users blade, and clicking Multi-Factor Authentication. This click path takes you to an ancient MFA configuration portal, shown in the next figure.

The original MFA configuration portal

The original MFA configuration portal

You still need this portal to configure the global MFA settings (such as choosing which MFA methods you will allow). However, you should no longer use this interface to assign MFA policy to your administrative or end users. I suggest you instead deploy MFA policy by using a conditional access policy, which I'll discuss momentarily.

As it happens, any MFA assignments you make in the old portal override conflicting assignments via conditional access. Thus, if you plan to use conditional access policy to enforce MFA, you'll need to use this method exclusively.

Somewhat confusingly, the Azure portal also includes MFA policy settings, as shown in the next screenshot. To sum up, use the old MFA portal and Azure portal settings to define how the MFA service works, and use conditional access policies to assign MFA to your users.

Advanced MFA settings in the Azure portal

Advanced MFA settings in the Azure portal

Second, create a shared, dedicated emergency administrator account. ^

I suggest you create a new Azure AD user account with the following properties and permissions:

  • A name that blends in with your end-user base; the idea is you never want this account to stand out to an attacker as an admin identity
  • A strong passphrase (Microsoft has some guidance on this in their docs)—the basics are your passphrase not only should be long but should not be a word in any language's dictionary and should contain alphanumerics and non-alphanumerics in mixed case
  • A policy in place that rotates the strong passphrase on a regular basis
  • Assignment to the Global Administrators Azure AD role
  • Assignment to the Owner role in relevant Azure subscriptions
  • Strong auditing of all the account's sign-in and control plane activity
Creating an emergency admin account in Azure AD

Creating an emergency admin account in Azure AD

This emergency admin account is obviously a super-duper identity, and you and your team need to be on the same page regarding its ongoing protection. You will use this account only during an honest-to-goodness MFA outage on Microsoft's side.

What's key here is that we will exempt this emergency admin account from our yet-to-be-defined MFA conditional access policy.

Third, use conditional access policy to deploy MFA ^

Here we come to the heart of the matter. You need to know that conditional access policy requires that you have either Azure AD Premium P1 or Premium P2 licenses. In my opinion, this is a no-brainer for any business putting their proprietary data into the Azure cloud.

If you aren't yet aware, conditional access policies allow you to define the entire environment that allows or denies Azure AD authentication attempts to the Azure portal and your cloud-based applications. For instance, you can enforce logins from certain geographical areas, compliance with sign-in risk factors, and hardware platforms.

Microsoft plans to enable the Baseline policy: Require MFA for admins conditional access policy by default in the future, so we'll customize this one today for our purposes.

Modify the Exclude users property to include your previously created emergency access account; I show you this in the next screenshot.

Customizing a built in conditional access policy

Customizing a built in conditional access policy

If you've been dragging your feet a bit on enabling MFA, I strongly suggest you enforce for all of your Azure admins at least. As I said, Microsoft will gradually force you into this configuration anyway.

For example, MFA is required to use Azure AD Privileged Identity Management (PIM). Azure AD Identity Protection is based around assigning MFA to users with sign-ins deemed risky by the Microsoft Intelligent Security Graph (ISG).

The idea of configuring your emergency admin account as an eligible admin with Azure AD PIM is a compelling one; this way, the account remains a standard user unless and until you or a colleague requests administrative elevation. Sadly, however, PIM requires MFA for activation of the Global Administrator Azure AD role.

In my next tutorial, I will show you how to use conditional access policy to accomplish two goals:

Subscribe to 4sysops newsletter!

  • requiring MFA for selected user populations
  • granting an emergency override to MFA to these users in the event of a Microsoft outage

See you then!

  1. Brian Pini 4 years ago

    Where is the follow up article


  2. Lil 3 years ago


    If MFA is enabled to user in MFA service and user settings set "Enforced", then if user Cookie expire, user is forced to do MFA challenge again. Even if user account is excluded from Conditional Access, still due user "Enforced" state user will be asked to run MFA.

    For enterprises, solution will be to setup Trusted IP's in MFA service and checkbox " Skip multi-factor authentication for requests from federated users on my intranet "

    Then in Conditional Access, under Location, set to Exclude "MFA Trusted IP's"

    Still all "travelers" will be affected and possibly their accounts should be disabled in MFA service and excluded from Conditional Access.

Leave a reply to Lil Click here to cancel the reply

Please enclose code in pre tags

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account