Table of Contents
October 15 Date for First Round of Azure MFA Requirement Enforcement
Microsoft’s decision to enforce multifactor authentication (MFA) for access to Azure properties certainly caused a great deal of kerfuffle. The original May 14, 2024 announcement didn’t help itself by proclaiming that “Microsoft will require MFA for all Azure users,” an assertion that led people to believe that any sign-in to Azure AD (Entra ID) would require MFA. At the time, I thought the idea is sound but the communication was woeful.
Roll forward to June 27, 2024, and a follow-up post to the Core Infrastructure and Security blog in the Microsoft Technical Community attempted to clear the confusion. Given the number of questions since, the signs are that people are still unsure what’s happening. Let me try to unravel the situation.
First, not everyone is affected by the change. MFA is only enforced for access to some Azure cloud properties. According to message center notification MC862873, Microsoft will require MFA for access to the Entra admin center, Azure portal, and Intune admin center (including services like Windows 365 Cloud PC) on or after October 15, 2024. Although I am not certain, Windows 365 Cloud PC seems like the only place where non-administrators might be affected by the MFA requirement.
Phase 2 of the implementation in early 2025 will see the requirement spread to the Azure CLI, Azure PowerShell, and infrastructure as code (IaC) tools. The good news is that only administrator accounts typically use these sites. Normal users are unaffected by the change. And anyway, administrator accounts should be protected by MFA. If they are not, the tenant has other problems.
Second, Microsoft 365 tenants that use Security Defaults already mandate MFA for connections to administrator portals.
Third, tenants that don’t use Security Defaults and have conditional access policies in place to control connections instead probably have a policy to require MFA for connections to administrative sites. Microsoft even publishes a policy template to make it easy for tenants to enable this control.
Workload identities, such as the managed identities used with Azure Automation, are unaffected. However, if Azure Automation runbooks include user identities (username and password credentials) for authentication, they might not work after Microsoft deploys the requirement for MFA access to Azure. For instance, if a runbook uses the Azure PowerShell module, it must use a managed identity or service principal (app) to connect.
Break glass accounts are affected too. If ever needed, these accounts are likely going to access Azure administrative sites and use Azure administrative tools, so the new guidance is to modify the previous practice of using a long and complicated password and add the protection for the accounts with a strong MFA authentication method like FIDO2 or certificates.
Postponing the Azure MFA Requirement
Microsoft says that they will allow a grace period to tenants who need some extra time. Organizations that use non-Microsoft MFA solutions might be in this category (support for external MFA providers is in preview). If in doubt, use the link in the message center notification post to request a postponement (Figure 1).
More information is available in the Microsoft planning document covering the new requirement.
Microsoft’s Script to Reveal Access to Azure Administrative Tools
In their post, Microsoft says that the Export-MsIdAzureMfaReport cmdlet from the MSIdentityTools PowerShell module as a way to uncover accounts likely to be affected by the change. The cmdlet “exports the list of users that have signed into the Azure portal, Azure CLI, or Azure PowerShell over the last 30 days by querying the sign-in logs,” so it’s a useful way to get an insight into who might be affected by the MFA requirement. I ran the cmdlet for my tenant and found that I need to act for an account used for utility background jobs (Figure 2).
The data used by the cmdlet is available to administrators to create their own version. For instance, the script covered in this article explains how to combine data from several sources to create a picture of MFA usage within a tenant.
No Need to Panic – the Azure MFA Requirement is a Good Thing
The bottom line is that there’s no need to panic unless you have a bunch of background jobs that use user credentials for authentication or forget to update your break glass accounts. Normal users will make unperturbed progress through the change. This is predominantly a good update to force administrators who haven’t yet understood the absolute need to protect their accounts with MFA to change their behavior. After all, why leave an open door ready for the bad guys to kick in?
Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.
So this overturns the previous advice of having a breakglass account exluded from all conditional access policies including MFA, which has a very long password printed out and kept in a safe (possibly half in one safe and the other half in another)
It does. You can continue to have a break glass account that is excluded from MFA and doesn’t use MFA, but if a problem happens that account will not be able to satisfy the requirement to undergo an MFA challenge to access Azure administrative tools. For instance, the account could access the Microsoft 365 admin center but not the Entra admin center. To make sure that the break glass account can access everything, it must be able to satisfy MFA. The recommended approach is to use a strong authentication method like a FIDO2 key.
Although I understand Microsoft’s point of view and strongly agree with them, the Microsoft-Managed Conditional Access Rules could have done the job. Break-glass accounts are sensitive and their whole purpose is to bypass anything including MFA. This adds a level of risk to these accounts (lost or broken fido2 key, …). Also, can’t seem to understand why Microsoft creates such “standard” things as CA rules, to replace Per-User MFA, they’re adaptive, “universal” in a way that allows Microsoft to push rules to tenant… just to create another specific thing in a dark corner of the room that does the same job but goes over it.
Thanks Tony
For the Microsoft-managed policy … “When you are ready to enable, switch its state to ‘on’. If you do not want to enforce this policy for your organization, switch its state to ‘off’. If you leave the policy in report-only mode, we will enable it for you.”
So if you set it to OFF now then MS will not auto-enable it in your org.
Thanks Tony
Do you know if this affects to the account used by Azure Ad Connect to synchronize on premise AD with Entra?
Thanks again for your great work.
Until now if MFA is enforced for this account then Azure AD Connect starts raising errors.
As I have no visibility into the tools you’re using (versions, configurations, etc.) or what you’re trying to do in your tenant, I suggest that you file a support incident with Microsoft and have their support engineers check things out. That way if an issue is discovered, it will be formally noted by Microsoft and sent to the relevant engineering team.
Hi Tony
We have a Conditional access policy set up to excluded account from MFA for mailboxes and automation accounts etc. Would the accounts in the policy stop working after the October date?
Thanks
Any account that does not satisfy an MFA challenge will be unable to connect to the Azure sites/administrartive tools after the requirement is imposed, so yes – if those accounts need to use the Entra admin center, Azure admin center, Intune admin center, Azure CLI, and Azure PowerShell.
What is accounts are behind Okta?
Microsoft supports MFA resources from non-Entra sources. You’ll have to work the details out with Okta, who are well aware of the situation.
thanks so much!