Protect Microsoft Admin Portals with SIF + (Phishing resistant MFA Or Compliant Device)

Source: Microsoft

The memo 22-09 utilizes Microsoft Entra ID as the centralized identity management system when implementing Zero Trust principles and requires employees using enterprise-managed identities to authenticate through multifactor authentication through the means of FIDO2 security keys or Windows Hello for Business to protect against phishing related online attacks.

There are multiple options for meeting phishing-resistant multifactor authentication requirements with Microsoft Entra ID. However, the trajectory should be towards implementing modern credentials. Some of the modern approaches are -

1. FIDO2 security keys which according to the Cybersecurity & Infrastructure Security Agency (CISA) is the gold standard of multifactor authentication.

2. Microsoft Entra certificate authentication without dependency on a federated identity provider.

3. Windows Hello for Business as phishing-resistant multifactor authentication

Access to Microsoft admin portals like Microsoft Entra, Microsoft 365, Exchange, and Azure is no different and Microsoft recommends securing access to them. This can be done in many ways and one of the ways that I am exploring in this article is through Sign-in Frequency (SIF) + Phishing resistant MFA OR Compliant Device. Here are the steps -

1. Navigate to Microsoft Entra admin center > Protection > Conditional Access.

2. Select Create new policy. (You can also create a policy using the Protect Administrator template, however, I chose to create it from scratch)

3. Give the policy a name.

4. Under Assignments, select Users or workload identities.

5. Under Include, select Directory roles and choose built-in roles. I have selected all 14 roles.

Global Administrator

Application Administrator

Authentication Administrator

Billing Administrator

Cloud Application Administrator

Conditional Access Administrator

Exchange Administrator

Helpdesk Administrator

Password Administrator

Privileged Authentication Administrator

Privileged Role Administrator

Security Administrator

SharePoint Administrator

User Administrator

6. Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts.

7. Under Target resources > Cloud apps > Include, Select apps, select Microsoft Admin Portals.

8. Under Access controls > Grant, select Grant access, Require authentication strength, select Phishing resistant MFA. Also select Require device to be marked as compliant.

Note: Phishing resistant MFA uses Windows Hello for Business OR  FIDO2 security keys OR Certificate based authentication as the flow. Since these flows require a managed device, you can also select require device to be marked as compliant as this grant control. This will also require a managed device targeted for a compliance policy through Intune.

9. Under Session, select Sign-in frequency and set the value for Periodic reauthentication. Note: Set it to a low frequency value for maximum security. For all intents and purposes, I am setting the re-authentication frequency to 1 hr.

10. Confirm your settings and set Enable policy to On. Note: Always set it to Report-only to test the effects first.

11. Select Create to create to enable your policy.

Testing Results

When a user with an admin role tries to access any admin portal like Entra from a device that is not managed, then the user access will be blocked despite satisfying the first level of authentication by providing the password.

This will be evident in the Entra sign-in logs as well.

However, when the same user tries to access the Entra admin portal from a managed device setup for Windows Hello, they will be granted access and the same will be evident in the Entra sign-in logs.

In case the Phishing resistant MFA authentication strength is not available or not satisfied, then device compliance will also get evaluated based on the Grant conditions.

SIF will also get evaluated based on the re-authentication frequency. There is no real way to capture this, however, in my testing I was asked to re-authenticate after 1 hr as per the configured value.

Final thoughts..

It is important to note that two portals ‘Microsoft Teams admin center’ and ‘Microsoft SharePoint admin center’ are currently not supported. However, these two along with others, are expected to be added in the future. Also, such policies can be restrictive therefore always ensure that you have relevant exclusions in form of Emergency or break glass accounts in place to avoid a lockouts. The end goal should be to protect all Azure resources so if you are ready to do so then consider adding ‘Microsoft Azure Management app’ to this policy as well. In case you are wondering what ‘Microsoft Azure Management app’ is all about, then it is an app which covers the following Azure services - 

-Azure Resource Manager

-Azure portal, which also covers the Microsoft Entra admin center

-Azure Data Lake

-Application Insights API

-Log Analytics API

Because the policy is applied to the Azure management portal and API, services, or clients with an Azure API service dependency, it can indirectly be impacted. For example:

-Classic deployment model APIs

-Azure PowerShell

-Azure CLI

-Azure DevOps

-Azure Data Factory portal

-Azure Event Hubs

-Azure Service Bus

-Azure SQL Database

-SQL Managed Instance

-Azure Synapse

-Visual Studio subscriptions administrator portal

-Microsoft IoT Central

So plan well, test in phases and implement it carefully. Until next time..