Just Dropped In (To See What Condition My Conditional Access Rule Was In): Part 5 – Require multifactor authentication for Azure Management

This blog is a series of guides which aim to run through the Conditional Access (CA) templates which Microsoft has published under the title Conditional Access templates (Preview). The templates get you up and running with CA but what is the impact of turning on the policies on devices, how can you adjust the templates to work in your environment and what does the end user experience look like on the endpoint?

The series is co-written by Paul Winstanley, a six times Enterprise Mobility MVP based in the UK and Mike Marable, an active member of the MEM community, based in the US.

Conditional Access Overview

Conditional Access rules are a type of if-then statement. If a user wishes to access something then they must complete an action to be able to access. Conditional Access rules get enforced once first-factor authentication has been completed.

Conditional Access use signals to make a decision and then enforce the decision to allow or deny access as per this diagram from the Microsoft documentation.

Microsoft introduced the Conditional Access templates at the end of 2021 as convenient method to deploy policies. These 15 templates cover five different deployment scenarios:

  • Secure foundation
  • Zero trust
  • Remote work
  • Protect administrators
  • Emerging Threats

This series will cover the 15 templates in detail.

Multifactor Authentication


Note the following pre-requisites to be able to tap into Multifactor Authentication (MFA).

  • Azure Premium P1 licences
  • Management of the policies via an administrator with either Global Administrator, Conditional Access or Security Administrator rights. Some MFA settings can also be managed by the Authentication Policy Administrator.


For an overview of Azure AD Multifactor Authentication, we recommend that you take a look at Part 2 – Require multifactor authentication for all users.

The Require multifactor authentication for Azure Management policy assists with protecting privileged resources when accessing Azure this can include:

  • The Azure portal
  • Azure PowerShell
  • The Azure CLI

These resources are grouped together and included in a cloud app called Microsoft Azure Management and we can use this app as the basis of the MFA Conditional Access rule.

If users have not onboarded for MFA when accessing the Azure resources for the first time, they will be prompted to onboard. For an example of onboarding MFA, when the user signs in, take a look at the section MFA Onboarding in Part 2 of our blog series – Just Dropped In (To See What Condition My Conditional Access Rule Was In): Part 2 – Require multifactor authentication for all users.

Require multifactor authentication for Azure Management

This Conditional Access policy requires multifactor authentication to be satisfied when users access Cloud Apps, use User Actions or Authentication context.

It is created in the Azure Portal under the Conditional Access\Policies blade, or in the Microsoft Endpoint Manager console under Devices\Conditional Access.

Click the New policy from template (preview) link.

The policy is available in the Secure Foundation, Zero trust, and Protect Administrator scenarios, or you can click All to display all the templates.

You can click the View option to view the default settings for the policy.

These are the settings for the Require multifactor authentication for Azure Management template.

Users:All Users are Included – The current user creating the
policy will be excluded
Apps:Azure Management
Access Control:Grant access – Require multifactor authentication

When the policy is created it is set as Report-Only. This is good practice, as the impact of enabling the policy can be assessed before doing so.

For our testing, we have created a group called CA Test User Group and added our test users to it. In the policy, under Users, we have chosen Select users and groups and picked the group to filter for. The user creating the policy via the template is excluded by default, but it is recommended to ensure you have a break glass account which can be used to access should the rule cause problems.

In the Access controls\Grant section of the rule, you can see that Require multifactor authentication is selected as the control.

When you are ready to move from the Report-Only mode, switch the toggle to On.

The state of the policy will be reflected in the console.

Assessing the policy with a What If

When you look to implement a conditional access rule, the What If policy tool is a great starting point to understand the impact of implementing the rule. The tool assess against a specific user and various scenarios can be input into the tool to get an end result.

For the MFA for Azure Management rule, we ran the tool against our Neil Redfearn test user.

You can access the tool from the What If link in the Conditional Access nav bar.

The first step is to select the user or service principal by clicking the No user or service principal selected link.

Enter your required user account or service principal.

Next, click the Any cloud app link and choose the relevant app, we have chosen the Microsoft Azure Management app for our test run.

As you can see, we are able to choose various different scenarios to test against such as originating IP address, device platform, sign-in risk etc. For our test the cloud app is enough to get the potential results we want to see.

Click the What If button.

The results are displayed below the What If button, take note if you have a smaller resolution.

By viewing the Policies that will apply section, you can see that the user is captured by the rule with the grant control being Require multifactor authentication.

You can also view the Policies that will not apply.

The tool is a great way of assessing your rules without having to run multiple logons on devices. However, it is always recommend to take a look authentications on your devices to ensure that the end result is as you would expect. Let’s see how this rule manifests on the endpoints.

Impact of enabling the policy

The following tests were undertaken on each device platform, the end result expected would be that we were prompted for MFA when accessing Azure resources. We tested the policy by authenticating into portal.azure.com.


On a Windows device, the user was prompted with Approve sign in request. Once approved, the user was able to access the Azure portal.


On a macOS device, the user was prompted with Approve sign in request. Once approved, the user was able to access the Azure portal.


On an Android device, the user was prompted with Approve sign in request. Once approved, the user was able to access the Azure portal.


On an iOS device, the user was prompted with Approve sign in request. Once approved, the user was able to access the Azure portal.


On an Linux device, the user was prompted with Approve sign in request. Once approved, the user was able to access the Azure portal.

Checking the Sign-in Logs

When it comes to investigating Conditional Access policies, we refer to the Sign-in logs in Azure Active Directory. You can check the sign-ins against an individual user by going into the the Azure Active Directory blade and selecting Users. Search for the user and select, then click the Sign-in logs menu entry.

On a Windows device, for the multifactor authentication sign ins, our user Neil gets in interruption in the sign in flow. Note the Status is listed as Interrupted. The additional details list the interruption as:

‘User needs to perform multi-factor authentication’

The next log entry reports a Success with the MFA requirement satisfied by claim in the token.

We can see that the policy has been applied with Success.

Note that the sign in events are different per OS and the above events give you an overview of a potential sign in record in the logs.

Further reading

Take a look at the following Microsoft documentation if you want to read some more on Multifactor Authentication and Conditional Access.

This is the last of the multi-factor authentication CA templates. Look out for the next part of the blog as we move away from MFA and dig deeper on the rules.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s