Requiring MFA for the Microsoft Admin Portal Apps 

New Changes to MFA

Multi-factor authentication is a powerful defense against a number of password-borne attacks. Reusable passwords are bad, but MFA helps make them less dangerous by blocking password-spray attacks and credential stuffing. The recent Microsoft digital defense report points out that just doing the basics (including adopting MFA) can cut identity-based attacks by 99%.  

Of course, “MFA” is a broad term, and some mechanisms are more secure than others. The Entra ID MFA suite covers the full spectrum from simple SMS authentication (which you shouldn’t use unless you have no alternative) up to robust authentication with context (including information about the app that’s requesting authentication and a small geo-referenced map showing the requester’s location) and number matching. 

This is all by way of saying that Microsoft has provided good tools, at no extra cost to its customers, to get MFA widely used with Microsoft 365. Recently, they made a relatively small change that lets you add an increased degree of security for a critical part of Microsoft 365: the admin portals. 

The Portal Problem 

From its earliest days, Office 365 admins (and, later, Microsoft 365 admins) have been pretty much required to use the admin portal to do some admin tasks. As the number of products in the suite has expanded, we’ve gotten new portals (think the Viva and Defender product lines), and the existing portals have evolved (as with the replacement of the old Exchange admin center with the new version, or the switch from Skype for Business Online to Teams). The portal apps are all hosted by Microsoft, in the *.microsoft.com domain, and they are meant to be accessible from anywhere you have Internet access. Although they have all sorts of risk-detection mechanisms running in the Entra ID infrastructure, they don’t have any mechanisms for you to restrict access to the portal; you haven’t been able to restrict access to specific geographic areas or to require specific or additional types of authentication. That means that an attacker who can compromise a privileged account can use it to get into any of the portals and start causing mayhem. 

How Conditional Access Helps 

The Entra ID conditional access system has a full set of capabilities to deal with exactly this problem. You can define policies that apply to, or exclude, any set of users you want, and then require whatever combination of six categories of conditions you want before users are allowed access to an application. The current categories are: 

• User risk
• Sign-in risk (if you have Entra ID P2 licenses). 
• What type of device the user is signing in from.
• The location (based on the IP address) that the user is signing in from. 
• What app the user is using (e.g. “Outlook mobile” or “browser”).
• Which specific device the user is using, based on device attribute filters. For example, you could allow access to the Microsoft admin portals only from a subset of devices that you’ve hardened as privileged admin workstations. 

Part of the policy is what Microsoft now calls “target resources,” or the applications and contexts you want to grant or deny access to. At this point, you might be wondering how CA can be applied to the portals. After all, to your computer, they’re just websites, and CA doesn’t have a way to apply policies to arbitrary URLs. Microsoft solved this rather neatly, by creating a cloud app object for the portals. In the same way that you can apply CA policies to specific Office 365 apps, you can specify target resources in a policy to require MFA for access to the portal. The “Microsoft Admin Portals” cloud app covers the Azure portal, the Exchange admin center, the Microsoft 365 admin center, the Defender and Purview portals, the Entra portal, and the Intune admin center. 

Creating the Policy 

To create the policy, follow the same basic steps as you would to create any other CA policy: 

1. Go to the Entra ID portal, then browse to Protection > Conditional Access. 

2. Select Create new policy and pick a policy name. 

3. Under Assignments, select Users or workload identities. 

• Under Include, select Directory roles and choose the built-in admin roles whose access you want to select. You should include at least a Global Administrator, User Administrator, and Password Administrator. You could also apply the policy to unprivileged users, but then they wouldn’t be able to access parts of the portals that they might normally use, including quarantined Exchange messages and the M365 admin center links to edit their own user properties). 

• Use the Exclude controls to exclude your break-glass users (as discussed below) and any other accounts that the policy shouldn’t apply to.  

4. Go to Target resources > Cloud apps > Include, then select the Microsoft Admin Portals app. 

5. Go to Access Controls > Grant, then select Grant Access. Then select Require authentication strength and Multifactor authentication, then click Select. 

6. Confirm your settings and click Create to create to enable your policy. 

Standard Warnings 

Microsoft knowledge-base articles used to carry a warning that editing the registry could be dangerous. In the same vein, they warn us now that it’s easy to accidentally lock out legitimate access with conditional access. Specifically, they recommend that you always exclude your emergency break-glass accounts and service accounts (this article has a few more suggestions you should be mindful of when creating new CA policies). 

Microsoft and I agree on recommending that you always create new CA policies in the report-only mode so that you have a chance to debug any errors in your policy definition before the helpdesk phone starts ringing. This is especially important with this policy since if you lock yourself out of the admin portals you’ll need to use a break-glass account to modify the policy.  

One additional warning: you can also apply CA policies to the Microsoft Azure Management app object. This will apply the selected policy to the Azure management portal, but also to a number of other Azure services, including the Azure Log Analytics API and Azure Resource Manager. Policies applied to Microsoft Azure Management may break automations or scripts you’re using. Don’t put policies on this object if you’re just trying to restrict access to the Azure portal itself. 

MFA Marches Onwards 

Most of us have learned to accept the occasional minor inconvenience of MFA authentication requests. Microsoft has done its part to minimize the inconvenience by giving us more flexible tools to apply the right level of additional security to the resources and users who need it the most, and this is a great example of their efforts. Requiring MFA for access to the admin centers will give you welcome additional protection at no monetary cost and with very little additional cognitive load. It’s well worth doing.