In August last year, I published eight articles in a series on Conditional Access, and later once finished I decided to bundle those articles in a paper which are now available on GitHub. You can find version 1.1. of the Conditional Access demystified paper there. You can expect a new version coming soon, since I have some information to add (the information in this article).
The articles I wrote at that time, will remain as is, and I’ve decided to update the paper once in a while to reflect the current status of Conditional Access. Even though some of the information in the articles is outdated, I still think that they can be of value.
Below I’ve summarized the articles I published last year:
In this article I’m going to share my default Conditional Access policy set. Even though each implementation of Conditional Access is different, the set I’m going to describe serves as a good basis for implementation. I will start describing what I want to accomplish functionally and how this is translated into a set of Conditional Access policies. There are quite some policies, but don’t let that scare you because once you understand them and relate them to the functional overview you’ll see that they are not that difficult.
Disclaimer: Implementing the Conditional Access policies in this article is at your own risk, make sure that you fully understand the policies before implementing them in your own environment.
The functional flowchart below gives an overview of what I want to accomplish, I always use this flowchart and adjust it where needed to determine the use cases which must be supported.
As you can see, the flowchart is situated around giving access to company data, since I think that Data is the asset you must protect using Conditional Access policies.
So basically we support several scenario’s in this flowchart, let me describe some of them:
In a default Microsoft 365 configuration, each user can invite Guest users into your Azure Active Directory. This is mostly done by either sharing a specific file hosted on OneDrive/SharePoint with that Guest user, or by inviting that Guest user to a Microsoft Teams environment, where that Guest user can participate in the team.
With Conditional Access policies we can control how Guest users can access the environment. The options we have are:
Allow full access to the environment
When you allow full access to the environment (which is the default), Guest users can use Desktop applications to access the data hosted by your company. In teams they are able to switch to your tenant and work in the teams that they are member of just like an internal user. They can even setup synchronization of SharePoint sites and have the data in that site available on their device.
You should ask yourself If you want to allow this, this totally depends on the data you are sharing with these guest users, in my opinion, if that data is confidential you shouldn’t allow that data to be one a device which you not manage. It’s also advised to implement a Governance procedure for Guest users and clean up once in a while, because without that Guest users can keep unlimited access the files shared and the Teams/SharePoint sites they have access to.
Allow Browser/Browser restricted access to the environment
We can also disable access via Desktop clients, and offer browser based access only. In this way we have some better control since we can apply App Enforced Restrictions to the browser session and by doing so denying users the ability to download and print any company data. I’ve described this scenario in the following article: Limit Access to Outlook Web Access, SharePoint Online and OneDrive using Conditional Access App Enforced Restrictions. We can have the restrictions on all the data, or on just a part of the data by using the sensitivity label functionality for containers.
Device Owner and usage
When it comes to device owner and usage, we have several options:
Company owned devices in most cases are devices, mostly Windows and macOS laptops which are enrolled and managed using Microsoft Endpoint Manager/Intune. The device has several policies applied, and we are able to measure if the device is compliant to our security policies by using Compliance policies. Mobile devices, can also enrolled and managed, but with the current capabilities of what MAM can offer, and the way these devices are being used, I see that less often. Even though there are endless possibilities to manage mobile devices using MDM, these implementations are complex and must also be maintained.
Personally owned devices, are owned by the user. In my opinion it doesn’t make sense to start managing those devices, and most of the time these devices aren’t even suitable to be company managed. If you ask the user bringing the device if he or she wants IT to manage the device, they will probably say NO. The Bring Your Own Device (BYOD) principle was a nice idea, but when it comes to managing a device and measure its integrity by using compliance policies, in the end you have to make the choice on whether you want to manage the device as a company yes or no. Managing a device comes at a cost and you should really ask yourself if the benefits outweigh the costs.
Company owned, personally used
When it comes to mobile devices, this is actually the scenario encountered the most. Even though the company bought the device, the user using the device considers it personal. So besides hosting applications containing company data, the device will contain personal email, personal pictures, personal apps and more personal data as well. If that is the current status of the device, you will have a real hard story to tell your end users if you want to bring that device back under MDM and fully manage it from that point forward.
Other Company owned
If you work with external consultants, but do supply those consultants with an Azure AD account (because you want those consultants to act on behalf of your company) it might be that those consultants already have a device managed by their own company. One of the limitations of MAM is that you cannot have more than one MDM solution managing the App. In that case the only option left over is to allow those external consultants to read their email using the web browser (which works quite well if you ask me).
The functional flowchart is my recommendation, it might be that you have another opinion or other requirements which require you to revise the flowchart. I think that the flowchart is a good starting point, in my work as a consultant I see many implementations where the IT department started with the Conditional Access policies, not having a clear idea on what they want to accomplish functionally.
The Conditional Access policies
Once you have consensus about how you want to allow access to your company data, you can start describing your Conditional Access policies, below is an overview of the Conditional Access policies covered in this article.
As you can see, the policies are divided into several categories which I use in the naming of the policies as well. For the naming I use the Microsoft recommended naming policy as described in this article: Set naming standards for your policies
The detailed settings of the policies described, can be found in the new version of the Conditional Access Documentation spreadsheet which can be found here: Conditional Access Policy Description-v1.2.xlsx
For each policy an exclusion group is created, and for each policy the group containing the break glass accounts will also be excluded from the policy.
Each policy has a version number in it, by doing so we can update policies with a new version, test this new policy on a select set of users and/or Report-Only mode and then make the switch by turning the old version off and implementing the new one.
The first category are the prerequisites and contains two policies.
CAP001-All: Block Legacy Authentication for All users when OtherClients-v1.0
This policy blocks all Legacy authentication when clients not supporting Modern Authentication are being used. For more information about this policy, please read the documentation from Microsoft: How to: Block legacy authentication to Azure AD with Conditional Access
Keep in mind that just disabling Legacy authentication in an existing environment isn’t a good idea. The end-users might still use applications only capable of performing legacy authentication and they might need your help first to transition to apps which support modern authentication. Please read the following article for more context and how to start your own project to phase out legacy authentication. Microsoft is going to disable basic/legacy authentication for Exchange Online. What does that actually mean and does that impact me?
CAP002-O365: Grant Exchange ActiveSync Clients for All users when Approved App-v1.0
Based on the functionalities provided, there is no use case to keep using Exchange Active Sync, that is the reason that we block Exchange Active Sync clients as well. Even though the policy grants, it actually blocks access to EAS clients because an Approved App is needed. (Outlook in our case). By using this mechanism, users still using EAS actually receive a message that they must transition to an application supporting Modern Authentication. If we would use a block policy, the user simply won’t get any email messages anymore.
The second category contains the policies for users and contains nine policies. Some of these policies require a Azure AD Premium P2 subscription, like CAU005 and CAU006 which require Azure AD Identity Protection and CAU004 which requires Microsoft Cloud App Security(MCAS).
CAU001-All: Grant Require MFA for guests when Browser and Modern Auth Clients-v1.0
This one makes sure that guest users are required to use Multi Factor Authentication (MFA) when accessing resources that you host.
CAU002-All: Grant Require MFA for All users when Browser and Modern Auth Clients-v1.0
This policy requires each user to use MFA when accessing cloud apps.
CAU003-Selected: Block unapproved apps for guests when Browser and Modern Auth Clients-v1.0
With this policy, you can create a list of Cloud Apps for which guest users are not allowed to use them. These apps can be apps containing sensitive company data for example
CAU004-Selected: Session route through MCAS for All users when Browser on Non-Compliant-v1.0
With this policy you can route the session through MCAS and its reverse-proxy capability, allowing you to either block downloads and monitor the session for strange behavior. In this example we block downloads for Cloud Applications specified if the device is not compliant.
CAU005-Selected: Session route through MCAS for All users when Browser on Compliant-v1.0
With this policy you can route the session through MCAS and its reverse-proxy capability, allowing you to either block downloads and monitor the session for strange behavior. In this example we just monitor the session on devices which are compliant.
CAU006-All: Grant access for High Risk Sign-in for All Users when Browser and Modern Auth Clients require MFA-v1.0
This policy will require MFA for sign-ins flagged as high-risk by Azure AD identity protection. See my article: Azure AD Identity Protection deep dive for more information
CAU007-All: Grant access for High Risk Users for All Users when Browser and Modern Auth Clients require PWD reset-v1.0
This policy will grant access for High Risk users after but only after they have reset their password. This functionality is also provided by Azure AD Identity Protection.
CAU008-All: Grant Require MFA for Admins when Browser and Modern Auth Clients-v1.0
This policy makes sure that Admins must always use MFA before signing in to any cloud application.
CAU009-AzureManagement: Grant Require MFA for Azure Management for All Users when Browser and Modern Auth Clients-v1.0
This policy makes sure that MFA is required when the Azure Management portal is requested. The reason for this policy is that when using PIM, your admin users might first go to the Admin portal, to request their rights using PIM afterwards. See: Lessons learned while implementing Azure AD Privileged Identity Management (PIM) for more information.
CAU010-All: Grant Require ToU for All Users when Browser and Modern Auth Clients-v1.0 (Optional)
CAU011-All: Block access for All users except licensed when Browser and Modern Auth Clients-v1.0 (Optional)
This one is optional as well, but I personally recommend it even though it’s a risky one. It will block access to any user which is not licensed. Make sure that you also exclude your admins from this policy. If you implement this policy you can really govern who can access the environment, but requires careful planning.
The device policies relate to the device the user is coming from. Keep in mind here that if a device which is managed but for some reason is not compliant, other policies apply targeted to non-compliant devices. In this case for example, the user will not receive any email anymore within the Outlook desktop client, but can login to the Office portal with browser based restrictions.
CAD001-O365: Grant macOS access for All users when Browser and Modern Auth Clients and Compliant-v1.0
Only grant access to Mobile Apps and Desktop Clients if the macOS device is compliant. In the policy below we exclude Guests and External users, allowing them to use Client Applications to access a Teams environment hosted in your tenant. If you only want to allow browser access (either full access or restricted) you should remove Guest and External users.
CAD002-O365: Grant Windows access for All users when Browser and Modern Auth Clients and Compliant-v1.0
Only grant access to Mobile Apps and Desktop Clients if the Windows device is compliant. In the policy below we exclude Guests and External users, allowing them to use Client Applications to access a Teams environment hosted in your tenant. If you only want to allow browser access (either full access or restricted) you should remove Guest and External users.
CAD003-O365: Grant iOS and Android access for All users when Modern Auth Clients and ApprovedApp and Compliant-v1.0
Only grant access if the iOS or Android device is compliant or if an Approved Client App is used. In the policy below we exclude Guests and External users, allowing them to use Client Applications to access a Teams environment hosted in your tenant. If you only want to allow browser access (either full access or restricted) you should exclude Guest and External users.
Microsoft is transitioning towards apps having a protection policy applied to eventually replace the Approved Apps functionality in some of the scenario’s. For now using this option isn’t advised yet since the Microsoft Teams app is not yet supported. See my article: Mobile Application Management for Mobile Devices with Microsoft Endpoint Manager/Intune deep dive
Did you know that even if your apps are managed by another company, you can switch profiles with Microsoft Edge. So in this case, even though the apps are managed by company A, you can switch the logged in session in the Microsoft Edge browser to company B requiring an Approved App as well. If you just want to be able to use any browser, don’t include the Browser option, and the user will then receive “CAD006-O365: Session block download on unmanaged device when All users when Browser” which uses App enforced restrictions. (no download and no printing) just as on non-compliant Windows and macOS devices. If you require that web access on mobile devices should only be possible from a managed browser (Microsoft Edge) you must include the Browser in the Client App selection.
CAD004-O365: Grant Require MFA for All users when Browser and Non-Compliant-v1.0
Require MFA if the device falls out of compliance.
CAD005-O365: Block access for unsupported device platforms for All users when Modern Auth Clients-v1.0
Block unsupported device platforms, like Linux and Windows Phone from accessing the environment.
Before you enable this policy, make sure that you have no “unknown” clients accessing the environment. You should check Azure AD sign-in logging as described in the article: Microsoft is going to disable basic/legacy authentication for Exchange Online. What does that actually mean and does that impact me?
CAD006-O365: Session block download on unmanaged device when All users when Browser-v1.0
This policy uses the App Enforced Restrictions, blocking download of files in OneDrive/SharePoint and Outlook Web Access. See: Limit Access to Outlook Web Access, SharePoint Online and OneDrive using Conditional Access App Enforced Restrictions.
CAD007-O365: Session set Sign-in Frequency for Apps for All users when Modern Auth Clients and Non-Compliant-v1.0
With this policy, you force users using Modern Authentication Clients to reauthenticate after a specified amount of hours/days. I normally set this to once per 7 days.
CAD008-All: Session set Sign-in Frequency for All users when Browser and Non-Compliant-v1.0
With this policy, you force users using the Browser to reauthenticate after a specified amount of hours/days. I normally set this to once per day.
CAD009-All: Session disable browser persistence for All users when Browser and Non-Compliant-v1.0
This policy makes sure that the session is not persisted in the Browser when the browser is closed. See: Understanding and governing reauthentication settings in Azure Active Directory for more information.
Location based Conditional Access policies relate to the location the user is coming from. I’m personally not a fan of excluding company locations from MFA policies. I had some cases for example where company cases were excluded, but came to the conclusion that the Guest WiFi network allowing all customers used the same internet IP address, making this network trusted as well.
CAL001-All: Block specified locations for All users when Browser and Modern Auth Clients-v1.0
If your company doesn’t do business in certain countries, you might as well block access from these countries. Even though there are ways to circumvent this (like using a VPN for example), it might make your security a little bit better than your neighbor.
CAL002:All: Require MFA registration from trusted locations only for All users when Browser and Modern Auth Clients-v1.0
MFA registration, is something that you might want to allow only when the user is in a trusted location. For example when onboarding the user.
Below is an overview of the functional flowchart, with tags for the Conditional Access policies. Even though the position of the CA policy is not always fully correct or can be applicable in more than one scenario, it gives an idea on where the policy is applied and might help while troubleshooting.
Implementing Conditional Access policies is complex, and should require careful planning. Only after several implementations I managed to figure out my own best practices which I shared in this article. Please use it for your own understanding, but don’t take my word for it, make sure you fully understand what you are doing before implementing your own CA Policies.