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 16 templates cover five different deployment scenarios:
- Secure foundation
- Zero trust
- Remote work
- Protect administrators
- Emerging Threats
This series will cover the 16 templates in detail.
- Part 1 – Block access for unknown or unsupported device platform
- Part 2 – Require multifactor authentication for all users
- Part 3 – Require multifactor authentication for admins
- Part 4 – Require multifactor authentication for guests
- Part 5 – Require multifactor authentication for Azure Management
- Part 6 – Require Password Change for High Risk Users
- Part 7 – Require multifactor authentication for risky sign-ins
- Part 8 – Use application enforced restrictions for unmanaged devices
- Part 9 – Require approved client apps and app protection
- Part 10 – Require multifactor authentication for Microsoft admin portals (Preview)
Multifactor Authentication
Pre-Requisites
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.
Overview
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 admins policy assists with protecting administrator roles in Azure AD. Accounts with assigned admin rights are targets for attackers. By enforcing MFA on these roles, you can reduce the risk of the accounts being compromised. We also recommend that you implement Privileged Identity Management (PIM) in your environment. Take a look at a two part series on PIM here.
When enabling the Require multifactor authentication for admins policy, 14 roles are protected by default. You can amend these, however Microsoft recommends protecting these roles and then adding to the list of protected roles.
The recommend roles to protect are:
- 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
Require multifactor authentication for admins
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 admins template.
To break down the policy:
| Included 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 |
| Apps: | All Cloud Apps are included |
| 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 the Require multifactor authentication for admins policy, the roles which will be protected are listed in the Assignments\Users section under Include\Select users and groups. Note the 14 default protected roles.
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.
Add a Role to the policy
To add a role to the policy, simply navigate to Assignments\Users\Include\Select users and groups.
Select or search for the role you wish to add and click the check box and Save.
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 if the user was assigned an administrator role. Our test user, Neil Redfearn, was added to the Conditional Access role. Allow users to remember multi-factor authentication on devices they trust was not enabled in the tenant. We tested the policy by authenticating into portal.azure.com. We enabled number matching for these MFA tests.
Windows
On a Windows device, the user was prompted with Approve sign in request.
Once approved, they were asked if they wanted to Stay signed in?
macOS
On a macOS device, the user was prompted with Approve sign in request.
The user was not prompted to stay signed in.
Android
On an Android device, the user was prompted with Approve sign in request.
Once approved, they were asked if they wanted to Stay signed in?
iOS
On an iOS device, the user was prompted with Approve sign in request.
Once approved, they were asked if they wanted to Stay signed in?
Linux
On a Linux device, the user was prompted with Approve sign in request.
Once approved, they were asked if they wanted to Stay signed in?
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.
For the Require multifactor authentication for admins policy we took a deeper dive into the sign-in logs and noted for each OS what the behaviour was in the logs. We noted that each OS had a slightly different behaviour in the log entries and that these events mostly replicated on each attempt but were not identical each time.
For the testing we ensured that the user was signing in fresh into a private browser session on portal.azure.com.
Here are the sign-in logs for each OS.
Windows
Here is the top level sign-in logs for the Windows authentication.
Each event is broken down as follows:
At 4:19:46, the log reported a Status of Interrupted for the MFA authentication requirement.
In Authentication Details, two events occur, Password auth has occurred with Correct Password as the result. Mobile app notification is recorded with Authentication in progress being the result.
Our Conditional Access rule for admins is reported as a Success.
At 4:19:48, the MFA is now reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details report that the MFA was previously satisfied.
Conditional Access reports as Success.
At 4:19:50, the Authentication Details events report that first factor and MFA have been previously satisfied.
Conditional Access reports as Success.
No further Windows events are logged and the user is now logged into the Azure portal.
macOS
Here is the top level sign-in logs for the macOS authentication.
Each event is broken down as follows:
At 4:20:18, the log reported a Status of Interrupted for the MFA authentication requirement.
In Authentication Details, Password auth has occurred with Correct Password as the result.
Our Conditional Access rule for admins is reported as a Failure.
At 4:20:28, the log reported a Status of Interrupted for the MFA authentication requirement.
The Authentication Details report that the MFA was successfully completed.
Conditional Access reports as Success.
At 4:20:32, the MFA is now reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details report that the MFA was previously satisfied.
Conditional Access reports as Success.
At 4:20:34, the log reported a Status of Interrupted for the MFA authentication requirement but the Additional Details report that this is not an error.
The Authentication Details events report that first factor and MFA have been previously satisfied.
At 4:20:34, the MFA is now reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details event report that MFA has been previously satisfied.
Conditional Access reports as Success.
No further iOS events are logged and the user is now logged into the Azure portal.
Android
Here is the top level sign-in logs for the Android authentication.
Each event is broken down as follows:
At 4:15:47, the log reported a Status of Interrupted for the MFA authentication requirement.
In Authentication Details, Password auth has occurred with Correct Password as the result.
Our Conditional Access rule for admins is reported as a Failure.
At 4:15:59, the log reported a Status of Interrupted for the MFA authentication requirement.
The Authentication Details report that the MFA was successfully completed.
Conditional Access reports as Success.
At 4:16:03, the MFA is now reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details event report that MFA has been previously satisfied
Conditional Access reports as Success.
At 4:16:09, the log reported a Status of Interrupted for the MFA authentication requirement but the Additional Details report that this is not an error.
The Authentication Details events report that first factor and MFA have been previously satisfied.
Conditional Access reports as Success.
At 4:16:09, the MFA is now reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details event report that MFA has been previously satisfied.
Conditional Access reports as Success.
No further Android events are logged and the user is now logged into the Azure portal.
iOS
Here is the top level sign-in logs for the iOS authentication.
Each event is broken down as follows:
At 4:14:13, the log reported a Status of Interrupted for the MFA authentication requirement.
In Authentication Details, Password auth has occurred with Correct Password as the result.
Our Conditional Access rule for admins is reported as a Failure.
At 4:14:26, the log reported a Status of Interrupted for the MFA authentication requirement.
The Authentication Details report that the MFA was successfully completed.
Conditional Access reports as Success.
At 4:14:30, the MFA is now reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details event report that MFA has been previously satisfied
Conditional Access reports as Success.
At 4:14:34, the MFA is reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details events report that first factor and MFA have been previously satisfied.
Conditional Access reports as Success.
No further iOS events are logged and the user is now logged into the Azure portal.
Linux
Here is the top level sign-in logs for the Linux authentication.
Each event is broken down as follows:
At 4:17:41, the log reported a Status of Interrupted for the MFA authentication requirement.
In Authentication Details, Password auth has occurred with Correct Password as the result.
Conditional Access reports as Success.
At 4:17:48, the MFA is now reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details event report that MFA has been previously satisfied
Conditional Access reports as Success.
At 4:17:59, the MFA is reported as a Success event with additional details of MFA requirement satisfied by claim in the token.
The Authentication Details events report that first factor and MFA have been previously satisfied.
Conditional Access reports as Success.
No further Linux events are logged and the user is now logged into the Azure portal.
Further reading
Take a look at the following Microsoft documentation if you want to read some more on Multifactor Authentication for admins.
- Common Conditional Access policy: Require MFA for administrators – https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-admin-mfa
Stay tuned for part four of the blog series.
SCCMentor - Paul Winstanley 
10 comments