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.
- 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
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 guests policy assists with protecting your guest users in your Azure AD tenant.
The flow is as below:
- An admin invites a guest to be able to access resources in the tenant which is set for MFA requirement.
- The guest user accepts the invite and signs in with their identity.
- The guest user is asked to complete a MFA challenge.
- The guest user sets up MFA and selects their MFA options.
- The guest user is allowed access to the application on completion of successful MFA.
Creating the Guest User
To create the guest user, sign into the Azure AD portal as an administrator.
In the Azure portal, select Azure Active Directory.
In the left menu, under Manage, select Users.
Select New user, and then select Invite external user.
Under Identity, enter the Email address of the external user. Enter any other optional information. Click Invite. An email invitation is sent to the user at that email address and the user is added to the Azure AD.
The user must accept the invite via the email sent to them.
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 guests
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 Zero trust, and Remote Work 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 guests template.
To break down the policy:
| Users: | Guests or External Users: B2B collaboration guest users (preview) B2B collaboration member users (preview) B2B direct connect users (preview) Local guest users (preview) Service provider users (preview) Other external users (preview) |
| 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 guests policy, the guest or external users which will be protected are listed in the Assignments\Users section under Include\Select users and groups. Note the 6 default protected guest/external user types.
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.
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 guest user attempted to authenticate to a cloud app in our tenant. Mike’s external account, 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 myapplications.microsoft.com and in the users profile we switched the organization to SCCM Solutions.
On the first authentication attempt, Mike was prompted to onboard to MFA as expected.
Windows
On a Windows device, the user was prompted with Approve sign in request.
macOS
On a macOS device, the user was prompted with Approve sign in request.
Android
On an Android device, the user was prompted with Approve sign in request.
iOS
On an iOS device, the user was prompted with Approve sign in request.
Linux
On a Linux device, the user was prompted with Approve sign in request.
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.
As you can see from part 3 of the blog series, the sign-in logs can differ on each sign in or for each OS. For the Require multifactor authentication for guest policy, we had identical events for most of our logins. This was a single event per OS authentication and is broken down as follows.
At 12:38:35, the log reported a Status of Success for the MFA authentication requirement.
In Authentication Details, two events occur, Previously Satisfied has occurred with First factor requirement as the result. Mobile app notification is recorded with MFA successfully completed being the result.
Our Conditional Access rule for guests is reported as a Success for Require multifactor authentication.
Further reading
Take a look at the following Microsoft documentation if you want to read some more on Multifactor Authentication for guests.
- Enforce multi-factor authentication for B2B guest users – https://learn.microsoft.com/en-us/azure/active-directory/external-identities/b2b-tutorial-require-mfa
- B2B collaboration overview – https://learn.microsoft.com/en-us/azure/active-directory/external-identities/what-is-b2b
Stay tuned for part five of the blog series.
SCCMentor - Paul Winstanley 
7 comments