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:
Conditional Access demystified, part 1: Introduction
Conditional Access demystified, part 2: What is Conditional Access?
Conditional Access demystified, part 3: How does Conditional Access work?
Conditional Access demystified, part 4: Designing a Conditional Access strategy
Conditional Access demystified, part 5: Implementing Conditional Access
Conditional Access demystified, part 6: Troubleshooting Conditional Access
Conditional Access demystified, part 7: Modifying Conditional Access to suit your special needs
Conditional Access demystified, part 8: Resources and further references
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.
Functional flowchart
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:
Guest users
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
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
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.
Versioning
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.
Prerequisites
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.
User
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)
This one is optional, but the policy requires users to agree to the Terms of Use (TOU) first, before they are allowed to access the resources.
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.
Device
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 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 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
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.
Conclusion
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.
Hi Kenneth,
Login into a work profile in Microsoft Edge brings some features to the user, e.g., SSO to M365 Web Apps or Browser Enterprise Sync. I like to restrict this features to be available on compliant devices only.
Are you aware of a solution on how to prevent a login to a work profile in Microsoft Edge on non-compliant devices (without affecting the general availability of M365 Web Apps)?
Hi Joe,
Thanks for visiting my blog –
I’m sorry, but I’m not aware of any way to restrict this.
Regards,
Kenneth
Hi Kenneth,
I would like to compliment you on this excellent post.
Following the set of rules, I end up with the following behavior on a non-managed machine with MAM-WE:
– Full access to OneDrive, Sharepoint and Outlook as apps with flagging as corporate data
– Downloading disabled as the device is not compliant.
Is there a way to enable downloading via Edge resulting in a company owned file on the non-managed machine while still blocking the downloading via other browsers that do not obey the MAM-WE policy?
Kr,
Roel
Hi Roel,
Thanks for the compliment.
I understand what you want to accomplish, but in the end it’s creating a security gap. You could for example exclude iOS/Android from the CA policy with the App Enforced Restrictions. That would lead to anyone on a mobile device (even not company owned) to be able to download files on those devices. Keep also in mind that mimicing coming from a mobile device can easily be accomplished using a browser plugin for example. If you would build this scenario, i would at least build the same policy for Android/iOS and keep it as Read Only, so that you can report on its usage and take countermeasures in case wrongly used.
Hope this helps,
Kenneth
Thanks for the reply Kenneth,
I was actually trying to target Windows 10 MAM-WE devices. On these, I think it would make sense to allow downloads. On those devices, edge would be included in the scope of MAM-WE and flag the files downloaded from Sharepoint or OneDrive as company owned.
However, I would need to be able to block browsers other than edge to access O365.
On mobile devices, I agree, I would leave the download from browser blocked.
Kr,
Roel
Hi Roel,
So you are talking about Windows Information Protection (WIP).
In my opinion WIP is not usable in these kinds of scenario’s – WIP is complex to implement, and I also think (but never tested) that an Office installation which has WIP policies applied is not considered an Approved and/or App receiving protection policy. So therefore we can’t manage that scenario with Conditional Access. I would stay away from implementing WIP, and if you really want protection on that level consider MIP/AIP/Labeling instead.
I don’t think you can achieve your scenario in this case, personally I would state that if you cannot manage the app or device you shouldn’t allow downloading/printing of company data on the device locally. Even though WIP is a sort of MAM, it isn’t treated in similar way to Android/iOS apps which have a MAM policy.
It would really be nice if Microsoft would come with a solution that we could also apply MAM policies to Windows (at least the apps from the store) and MacOS. Then the solution would be unifor across platforms.
Regards,
Kenneth
Hi Kenneth,
A great article and provides a lot of guidance in implementing a Conditional Access strategy. I had one question around MFA when using Azure Identity Protection that I am just trying to work out in my head.
How do CAU006 and CAU007 interact with CAU001 and CAU002? E.g. if an internal user was signing in and the sign-in/user risk was measured as say low by CAU006 and 7, would they still see an MFA prompt due to CAU002?
Many thanks and keep up the great work!
Hi Ben,
Thanks for visiting my blog.
Concerning your used example, the user must meet the MFA requirement in this case indeed, that doesn’t necessarely mean that he/she will get prompted though. For example on a device with WHfB the MFA requirement if fullfilled by WHfB itself. Also keep in mind that CAU001 and CAU002 are targeted to browser only, while CAU006 and CAU007 also include Modern Auth Clients.
Hope this helps
Regards,
Kenneth
HI Ben, thanks for your real helpfull article! In the beginning you write, that personally owned devices shouldnt be managed with mdm, as most userswill propably not register their devices in a company owned environment. Which of your policies gives access to personal owned devices without doing so? I havent implemented your rules yet, but for me every policy looks like the device has to be registered, so that a Compliance-Check can be made first. Reason why im asking is, I want to give access to all personal owned devices without registering in mdm.
Best regards
Hi Sebastian,
In my baseline, personally owned devices used by your users can only use browser based access (with restrictions) to access the environment. Usage of desktop applications to access EXO, SPO or OneDrive is not possible for the reason that since we don’t manage the device we cannot control the data on the device either. In my opinion this could be solved by a good MAM solution on Windows. I don’t consider WIP a good solution though, let’s hope MS fixes this somehow in the future.
/Kenneth
Great post although should CAU005 Client App only be browser, as opposed to browser and desktop clients?
Hi Nathan,
Correct, you are absolutely right. CAU005 client app should only be browser. I will correct this in the next version of the whitepaper.
Thanks for bringing this to my attention
/Kenneth
Awesome, thanks for taking the time to get back to me, great to hear that you’ll be doing an updated version as well – Fantastic article that really helped me step up my CA game! Thanks!
Just noticed, should CAD002 only be ‘Mobile Apps’ or should both ‘Browser and Mobile Apps’ be ticked?
Hi Nathan,
Thanks for the comment: CAD002 is only for Mobile Apps, we want to allow browser based access from non-compliant devices (for O365 with App Enforced Restrictions)
/Kenneth
Thought so and I think I actually meant CAD001 which says Browser & Mobile Apps but I think the title should just be Mobile Apps! Thanks again for quick response!
Hi again – should: CAD005-O365: Block access for unsupported device platforms for All users when Modern Auth Clients-v1.0 be set to both Browser and Mobile apps and desktop clients as opposed to Browser only?
Hi Nathan,
In my opinion it will depend, Modern Authentication clients for sure, but browser is debatable.. if you have your app enforced restrictions/routing through MCAS in order I don’t see any reason to block browsers on devices not supported.
/Kenneth
Hi Kenneth, thanks for the reply – In which case your CAD005 policy is incorrect as it currently targets only Browser under modern auth clients – Just out of curiosity, when do you expect to be publishing the next up to date whitepaper? Your policies are very much in line with what I was always trying to achieve with a default set of policies, thanks
Hey Nathan,
You are right, in the new policy baseline I have set this to Browser (Optional) – but I’m not going to modify this article and will redirect users to the latest version of the baseline instead. Which will release very soon 🙂
/Kenneth
Hi Kenneth,
CAU002 requires mfa for all users for browser and modern auth clients
CAU008 requires mfa for admins for browser and moderne auth clients
CAU009 requires mfa for azure management for all users when browser and modern auth clients
When a global administrator tries to do Azure management tasks via the browser he normally should get all three Conditional Access policies. Any reason to split them all up if you already have CA0002 which covers all ?
Thanks in advance.
Hey Tim,
Thanks for visiting my blog and leaving a comment.
CAU008 and CAU009 cover the scenario where PIM is used to elevate rights, let me explain further.
If an admin (who is not elevated yet) goes to the Azure Portal we want to make sure that they do MFA (CAU009), once in the portal they do a PIM and receive one of the administrator roles which we cover in CAU008.
But you are right, in most cases because they satisfied the MFA in CAU002, they will not be prompted again and sometimes the policies overlap. The don’t bite though, which is important 🙂 and are just a safety measure based on some scenarios I defined.
Hope this helps,
Regards,
Kenneth
Hi Kenneth,
Thank you for the guidance with CA and going modern as a philosophy! For CAP002 you mention EAS users receive a message they must transition to a modern auth app – does EXO send this down to all EAS clients or does this mean ‘existing EAS users can still receive mail guiding them to switch to a modern auth app from IT’. If it is a system generated can you explain how/when this is triggered?
Hi Jessinba,
The idea is that once the policy is enabled, the user receives one last email on the currently in use mailclient with information about how to transition to a mail client supporting APP (read Outlook)
Hope that makes sense, and thanks for visiting my blog
/Kenneth
Great article and guidance thanks for producing it. Where did you protect your global admin accounts?