On the logic of access constructed through Microsoft Conditional access
There is a special logic to Conditional Access. The Team and I been working in the logical structure for a while and would like to show a little bit of the fun things we’ve done! In addition we’ll walk through a few pitfalls, why you need break-glass global admin accounts, and a few other interesting solutions.
What’s Microsoft Conditional Access?
Microsoft Conditional Access combines signaling and context into the authentication process. Depending on your configuration you can filter for location, application, device and more! In this article we’ll look in on several different configurations and explain the concepts. In the end I’ll show some of the customer requests I’ve received over the last few years.
Normally when you try to log in to Microsoft 365 services, you should be presented with the following picture:
This is the world’s most secure login-page. I’ve worked for hours trying to scrape it, but I simply can not. If you have configured a device policy to block unmanaged devices, you will get the following message:
The error message I’ve pictured here doesn’t perfectly encapsulate the returned information, as it eludes to several issues with this login. First one is the failed challenge on access from non Azure or Hybrid AD Joined devices, and the second one is the Microsoft Defender for Cloud Apps approved browser signal evaluating the browser you’re connecting with. The reason for checking the browser signal is to make certain the browser enforces MDCA or conditional access restriction policies correctly.
Why you need Break-Glass Administrators
Before we start talking about Conditional Access policies, we need to talk a little bit about what Microsoft calls “Break-Glass” Administrators. These administrators should have a strong password (preferably 128 characters), be collected in a group (for easy assignment) and be exempt from all conditional access policies. The reason for this is to be able to get back into your tenant to turn off conditional access policies should the Microsoft Multi Factor Service go down like it did in september 2021.
Always make certain you store the passwords in a safe place you can get to without having to log in to Microsoft services. This means: Don’t store passwords for Break Glass administrators in SharePoint or OneDrive or OneNote or any other Microsoft application. However, you’ll need to store them in a safe place, preferably a non-Microsoft connected key-vault.
In the description of the different Microsoft Conditional Access policies in this article one thing is always true: It is implicit the Break-Glass Administrator group is configured as excluded in the users assignment. Always make sure you have a way to turn restrictions off.
The same thing goes for you, the administrator. Never lock yourself out. Always be careful whenever you’re using the “all users” assignment, and never include yourself in policies you’re testing.
User Multi Factor Authentication Policies
Multi Factor Authentication consist of two or more of the following:
Something you know – Often considered your username and password for instance. The reason your username and password are not considered two factors are because they’re both “something you know”.
Something you are – Meaning biometrics like your fingerprint, face or iris.
Something you have – Meaning your phone, a hardware token, key or something else like a smart card.
Something you do – This could be like how fast you write something on a keyboard, a rhythm of an action you do or how you walk.
In Microsoft 365 there are two ways of activating multi factor authentication for users, Office 365 MFA or Microsoft Conditional Access. The Office 365 solution uses a user-by-user function where you move users from enabled to enforced by activating the multi factor requirement.
The portal looks like this:
And you can mark the users and enable the multi factor requirement by flipping the status from “Disabled” to “Enabled”. When the user has registered and configured it will automatically flip from “Enabled” to “Enforced”. The reasons you should use Microsoft Conditional Access instead are many, but here’s a quick rundown:
– Difficult “mass” changes. You’ll need to use CSV bulk update to configure several users.
– No session controls. Users will be requested for MFA every time their session times out, or with every new device.
– No advanced features like governance controls or similar access restrictions.
Activating User MFA in Microsoft Conditional Access is super simple, just configure the following function:
The idea is simple. When any user logs on to Microsoft 365 using anything – You don’t really need to configure any of this, just use the “not configured” setting for most of them, and you’re fine. Whenever the user logs in from anywhere, you trigger a multi factor challenge. The main point to always remember in Conditional Access is that either you either configure it to be evaluated or you leave it out. I drew the logic here:
You can use this to configure the logic you need. Take for instance who is triggering the authentication? What user, group, privilege or authentication context is used? You could consider the application endpoint you’re reaching (the end application, like Exchange Online) – this needs to be configured in order for the policy to be valid – You include it and when you get to conditions and configure an inclusion on the client app you’re protecting. At the grant level you should then configure either a multi-factor challenge to be performed, or simply block it if that’s what you’re trying to do.
I drew up the logic a little clearer to describe the process better – For each square you go down, and not left, you’ve configured an include of some sort. Users included, cloud applications included and so on. Left is excluding, but it’s important to remember include and exclude are not mutually exclusive. This means you can include something and exclude others. It’s important to always remember is when you exclude something, it is exempt from the policy.
Require MFA for Administrator Roles
Administrator MFA requirements are common in modern customer networks. There are several ways of doing so, but the best way is to use the privileged role as the user inclusion to trigger a grant with MFA requirement. I’ve drawn it for you below.
You could always do this a different way if you’ve chosen to assign privileged roles using Azure role assignable groups instead, by choosing to use that is the user inclusion instead. I’m often required to use exclude conditions like location for all company IP addresses to make sure the MFA requirement doesn’t inhibit business processes while in the office. It’s common to call being on the company network a second factor in that aspect. – How believable that is considering Norwegian physical perimeter security is debatable however.
Be careful when you’re activating this policy, as you’re an administrator. In addition you’ll need to constantly keep this policy updated. When I started configuring Conditional Access policies 4 years ago, there were around 35-40 privileged roles – today there are 75.
Risky users and risky logins
Risky user/login policies configured under the Azure AD Premium Plan 2 offering are actually conditional Microsoft Conditional Access structures, but you can expand them to conform with your business processes instead of using the presets.
Remember, you can configure risky user settings to do anything. In the drawing below I’ve only shown you what the classic user risk policy with Password changes for user risk and MFA challenge for sign-in risk looks like on the back end, but you can make it much better.
My personal favorite is to configure user and sign-in risk to trigger Conditional Access App Control when the business requires security, but no cut in access. This would mean the user would be allowed to read and work in the web portal, but not download the accessible documents,
Sometimes you need to enforce approved clients
One of most annoying things I see in Enterprise environments is the use of native applications. Too many times have I had conversations with proud IT department heads saying they have blocked legacy authentication applications, only to allow Apple IOS Accounts, Gmail, Samsung Mail or Android Mail applications in Azure AD. This opens up the company to Exchange ActiveSync even if you have blocked it as an authentication protocol. Using the drawn policy below, you can force the users to use the business approved application in order to be allowed to log in and use SharePoint and Exchange Online. If the user tries to log in using a non-approved client, they’re forwarded to download the correct application.
Block legacy authentication
As we just spoke about blocking legacy authentication, I wanted to have a little conversation about it. One of the greatest authentication risks today are old authentication models who do not support multi factor or other security controls. Some of these are old, and other of them are very old. Microsoft references this table: here
All of these are considered legacy authentication models. The most commonly – legitimately – used of these protocols are Exchange ActiveSync and Authenticated SMTP, where EAS is used by native mobile applications and authenticated SMTP for systems like Multi Function Printers who provide scan-to-mail services.
Below I’ve drawn up how the Conditional Access policy looks at the issue:
You could in theory require MFA instead of simply blocking them, as MFA is not supported, but that would be an incomplete policy and prone to failure. You should make certain users can not consent to applications as well, to lock out native applications who allow legacy authentication regardless of the tenant policies. User application consent will be a topic of a later post.
Force session controls
In OpenID there are two different tokens. There’s the Access token and the Refresh token. They both have different time to live (TTL) timers, setting how long they remain valid after the authentication has taken place. The Access token is used to authorize a request to a server and is normally attached to all requests performed. This is to ensure no non-authenticated API calls are responded to from the server. However, the refresh token is used to allow the user a new access token after the access token has expired without having to perform a new authentication process. Take for instance the Microsoft login process asking you if you want to remain logged in – that’s setting the max-age of the refresh token to allow your session to remain open for much longer.
This can however be changed using Conditional Access policies, by forcing session controls on the user. I’ve drawn up a basic policy, but you can by now expand it much more. You could for instance configure it to only trigger for unmanaged devices in situations where the business requirement is to force re-authentication often instead of blocking access. Otherwise known as the “bug them to death” approach. This would allow users access from any device, but force them to keep authenticating regularly. This would be the perfect approach if you’re trying to defend against users forgetting to log out of publicly accessible computers.
Intune App Protection policies
Intune app protection is a different beast than the policies we’ve been talking about so far as it uses other modules of the Microsoft 365 suite, namely the intune endpoint manager. Policies running on the “intune app protection policies” condition use the Mobile Application Management structure of intune, allowing the endpoint manager to enforce application configurations.
One example of this is to configure Microsoft Edge – Windows Information Protections settings refusing users to relocate data from protected applications. This could mean SharePoint or Exchange for instance, where you would be unable to export, move, have other apps interact with or download data. You can then enforce what corporate identity the user needs to log in with, and how it’s maintained.
The advanced page includes information like what Azure Rights Management System template to use and whether to informing users using icons. You can configure network boundaries and other proxy related settings before activating the policy, even choose what file extensions are evaluated by the policy. In the case of this Conditional Access policy, you could enforce the policy for non-managed devices and make sure the user is authenticated with a MFA challenge before allowing the limited access. This is a great way to allow access, but refuse users “dangerous” actions. When activating the following policy in SharePoint, you’re in essence using a limited set of the configuration functions:
You can see the resulting configuration below. Open it using right click and open in new tab. The picture is sadly too large for WordPress to comfortably handle.
The point is to know the only way an unmanaged device will be able to reach this cloud application is to use the browser. This means the user can not download or sync data using the desktop OneDrive application – without being Hybrid or AAD Joined.
One thing you as the administrator will have to be very conscious about is the lack of App Protection Policy support for Microsoft Kaizala, Skype For Business and Microsoft Visio. Requiring app protection for these applications will not work as you intend and may lead to authentication and license validation failing. I’ve drawn it up below, with the exclude included in the workflow.
Microsoft Defender for Cloud Apps
Policies in this category use Conditional App Control functionality through Microsoft Defender for Cloud reverse proxy structures. The idea is to force your connection to the cloud application to be evaluated through the MDCA proxy, allowing the organization to restrict certain actions like downloading documents from the service. The computer does this by visiting the MDCA proxy on the way to the application – visualized like this:
The point is to make certain the user can not reach the application directly, but force user action evaluation in the application through the reverse proxy. There are several settings required to configure this completely – and I’ll take you through them. The first one is to allow MDCA file access. Without this option, the MDCA reverse proxy will not be able to evaluate file actions in your cloud applications like OneDrive and SharePoint. I imagine you know how to get to the MDCA portal.
First, open Settings, found in the cogwheel top left. Then open the file under “Information Protection\Files“.
You will then get the following setting: – just without the tickbox active. Tick it and press save.
After this has been performed you’ll need to onboard the OneDrive application to MDCA proxy. You can do this in the MDCA connected apps menu. Then you press the context button (three dots) and press “edit app”. Here you’ll need to tick “Use with Conditional Access App Control”.
There are no reason to change the app domains, as the app domains are pre-filled by Microsoft, but if it was a custom application, you would have to. The “block downloads” policy is pre-filled in the Conditional Access panel as well. You can create your own policy and restrict further functionality (using a governance or application policy in MDCA) like:
– Block download, cut, copy and print
– Require MFA on download of confidential files
– Prevent upload of unlabeled files
– Block potential malware by scanning against MS Threat Intelligence
– Monitor user sessions for compliance
– Block access on risk factors
In the drawing below, I’ve taken the liberty of just covering the basic functionality. MDCA policies and functionality may be a question for a different post.
The policy itself relies on the unmanaged device to work. What it means is that you’ll have to use device filtering defined in the Customer use cases further down.
After the policy is created and basic setup of the protected application is configured in the MDCA reverse proxy, the only activation you’ll need to do is to flip the “Use Conditional Access App Control” and choose the policy you want to use.
What’s the difference between MDCA and Intune App Protection Policies?
Both MDCA and Intune app protection policies makes certain the users get a restricted functionality out of the applications, where MDCA takes control over the user sessions and evaluates signals and actions – while Intune app configurations restrict access to work data stored in cloud applications without interrupting the user’s access to personal data. Intune app configurations make further changes on how data in the application is accessed, using policies to control how data is moved between applications and the device itself. MDCA perform much more in depth evaluation of signals and integrates with user actions to control what’s allowed and not. The greatest part of both of these are how they’re integrated with the application and it’s data, and does not need an enrolled device to be effective.
I’m often asked to define the difference between the two approaches, and the answer I give is twofold: Firstly it depends on how involved you want the systems to be. Do you want a reverse proxy system who evaluates user actions or a policy control system protecting the data stored in the application? Are you protecting based on user signaling or on the way applications interact with the stored data? Second, it’s a question of licensing. MDCA is significantly more expensive than an intune license.
In an effort to visualize it, I’ve drawn up some of the functions available in both of the different session controls:
Customer use cases
Customer use case: Block unmanaged windows machines from downloading documents from OneDrive and SharePoint.
There are several layers to the details of this request:
– The organization uses more than one client management systems
– SCCM and Intune (this will become important later)
– All managed computers are Hybrid AD joined
– Locking unmanaged devices out of work is unacceptable
– MFA challenge must be passed on unmanaged devices to authorize the user
– Preferably use compliance controls to deliver limited access to internal computers who fail to meet corporate compliance requirements
Referencing the above information we use two systems: App enforced restrictions and MDCA block downloads. First of all we want to use the App enforced restrictions to set the unmanaged device ruleset. In addition we want to use the MDCA reverse proxy functionality to block users from downloading files from the SaaS applications. Explaining the drawing below:
1. Users who log on to Exchange online, Sharepoint Online or other file storage applications
2a. Using AAD Joined Device -> Approved without limitation through exclusion
or
2b. Using MFA challenge -> Will be delivered the restricted experience
3. Session controls are enforced
Device platforms are configured like this (as only Windows devices can be Azure AD Joined, including other platforms will not work as you intend.
Client apps are configured like this:
Grant configuration is set to either require MFA challenge or Hybrid Azure AD Joined device.
The session controls are configured like this:
The reason the logic of allowing Hybrid AD Joined devices is important is because the organization can’t use compliance controls. As the environment is co-managed with SCCM, compliance controls are unavailable in the Intune service. In the intune service will the compliance control just return “healthy” or “unhealthy”, but Conditional Access does not support this notation. The added point is to allow company controlled devices a “way out” of the policy.
The reason the logic of allowing Hybrid AD Joined devices is important is because the organization can’t use compliance controls. As the environment is co-managed with SCCM, compliance controls are unavailable in the Intune service. In the intune service will the compliance control just return “healthy” or “unhealthy”, but Conditional Access does not support this notation. The added point is to allow company controlled devices a “way out” of the policy.
The reason the logic of allowing Hybrid AD Joined devices is important is because the organization can’t use compliance controls. As the environment is co-managed with SCCM, compliance controls are unavailable in the Intune service. In the intune service will the compliance control just return “healthy” or “unhealthy”, but Conditional Access does not support this notation. The added point is to allow company controlled devices a “way out” of the policy.
The reason the logic of allowing Hybrid AD Joined devices is important is because the organization can’t use compliance controls. As the environment is co-managed with SCCM, compliance controls are unavailable in the Intune service. In the intune service will the compliance control just return “healthy” or “unhealthy”, but Conditional Access does not support this notation. The added point is to allow company controlled devices a “way out” of the policy.
Customer use case II
Customer use case: Block unmanaged mobile devices from using Approved Clients to sync with OneDrive, SharePoint or Outlook.
The same client required a policy to block devices who’re using the approved clients (Microsoft applications or the Nine email client, for some reason), but not owned by the organization should be blocked. This policy should lead to the “you can not get there from here” message. However, the policy could not block the application endpoint, as the browser access should still be allowed.
First thing in the logic is to set a strict block on all devices logging in using iOS or Android with any mobile application, except the ones the company owns. This would exempt the owned devices from the policy and force enrollment before the application functionality would be restored. Then you filter on the applications you want to filter away in this setting (anything but browser applications).
Device platforms included are only mobile devices, because the inclusion is on all mobile devices before we start filtering some of them away again:
The client app configuration excludes the browser. That’s because we want the browser access to be limited differently, meaning you need a different policy for it. As an identity administrator you’ll need to be able to know when one policy stops and another starts. You can’t do everything in one policy.
Because we started with “all mobile devices” – we’ll need to filter away the devices the organization owns using a device filter.
This will allow your owned (or registered as this customer used) devices to access the system normally, but non-owned devices will be blocked in the login process for the approved clients:
Drawing it up in a more complete way:
Closing arguments
The idea of Conditional Access is to allow company policy to form the authentication process using a logic structure and comprehensive context and signaling filters. Mastering the logic and how to present it to your customers is paramount to a successful implementation greater than the first two layers of User and Admin MFA.
All too often are technical documentation of technical things written by overly technical people. The goal of my blog is to explain complex technical concepts in easy to understand terms with simple visualizations making it easy to explain to customers or your own leadership how to implement different technologies. Being a great consultant is not about being the best at technology. Far from it. It’s all about communication. If you can’t explain to your users why pressing a phishing link is a bad idea in easy to understand terms, you can be the highest certified person in the room and still not get the job done. We can be better than this. I believe in you.
Thank you for reading
I sincerely hope this helps someone.
If you’ve read this and would like to say thanks or have any feedback, let me know on Linkedin! Find the .pdf version of the pictures below.
/James