Cloud Access Control
Compared to an on-premises environment, cloud access control is quite different. While on-premises access controls are often centered on firewalls hosted in the internal network, this does not translate to the cloud – an important fact often overlooked during migration projects.
Since Microsoft 365 tenants use Azure Active Directory for authentication, by default, any user can connect to Microsoft 365 workloads from any place, at any time. While this is great from a productivity standpoint, it definitely raises some security challenges. For example, attackers can execute a password spray attack to guess the password of an account. And because attackers attempt to compromise account credentials, it’s critical to secure access to Azure Active Directory.
Conditional Access (or CA) policies allow you to create rules (or policies) that dictate how a user authenticates to Microsoft 365 and if they must adhere to certain controls. However, Conditional Access isn’t something to quickly dive into without much thought. Instead, you need to really think about what you want to accomplish to secure user connections, which is what I’ll discuss in this article.
Getting Started with Conditional Access
At first, figuring out how to implement Conditional Access can seem daunting since many configuration options exist, and some with little guidance around. The way I see it, Conditional Access policies are specific to an organization and its requirements, and no perfect set of policies exist that work for every organization.
It’s important to note that Conditional Access is an Azure AD Premium Plan 1 feature, so it’s not available in every tenant but it is included in several Microsoft 365 SKUs:
- Enterprise Mobility & Security E3
- Microsoft 365 E3
- Business Premium
Unfortunately, some organizations will try to circumvent this requirement and attempt to migrate on-premises firewall policies to the cloud to replicate access controls. This approach is wrong – the cloud is an entirely new way of working and access control needs to be managed as such. The days where attackers only use IP ranges from specific countries are long behind us and creating IP-based restrictions (either to block connections from certain countries or only allowing certain IP-ranges) will only give you a false sense of security hinder end-user productivity.
Designing Conditional Access Policies
When designing Conditional Access policies there are several actions you need to take and things you need to keep in mind. These are basic concepts and actions, but they are extremely important:
- Confirm the user’s identity during sign-in.
- Validate the security of the device used for the connection.
- Enforce stricter controls for administrator accounts.
Microsoft does provide some templates through the Azure AD portal which are a good way to get started, and I found this Microsoft documentation to be extremely helpful as well.
Additionally, there are a few default policies which I recommend that every organization implement:
- Require MFA for users when using non-corporate devices.
- Require a corporate device when using desktop applications.
- Require MFA for administrator without any exclusions.
Improving MFA Efficiency
While Multifactor Authentication (MFA) contributes to a more secure account, spamming users with MFA challenges isn’t always the best solution. If users become accustomed to approving MFA requests, they can fall into the trap of approving challenges without thinking. In turn, this could mean that someone accidentally accepts a sign-in request generated by an attacker which then enables the attacker to compromise their account. While number matching alleviates this issue, user experience is extremely important when implementing Conditional Access policies.
I recommend implementing Conditional Access policies the smart way. Instead of challenging a user with MFA at each login, try to combine other trusted signals to verify the identity of a user. This could be the state of the device (which uses device compliance from Microsoft Intune) or the user’s location (logging in from a known location). By using multiple signals before issuing an MFA challenge, you will drastically reduce the number of challenges a user receives and how much they’re inconvenienced by it.
Read more: Taking Control of Your Unmanaged PCs with Intune
Protecting Data
Conditional Access supports many features besides MFA you’ll want to consider in your implementation. A big plus is the ability to grant granular access to data through Microsoft Defender for Cloud Apps for example, or block access entirely.
Most organizations aren’t aware that anybody can install Outlook and OneDrive for Business on a personal device, and then copy mailbox and document data to that device. In this scenario, when an employee leaves, you have no control over any data copied to their personal device and they can walk out of the door with that data in their pocket. Ensuring that users can copy company data only to company devices is a wonderful use of Conditional Access.
Less is More
Depending on the complexity of the conditions an organization tries to cover, implementation can become cumbersome when it results in a large number of policies. Within larger organizations, I have seen fifty or more policies in use. When the organization wants to change a policy, or the help desk needs to troubleshoot a sign-in, a high number of policies involved with processing sign-ins can make this effort extremely challenging. Therefore, it’s important to think about the big picture at the beginning of this process so you combine as many conditions as possible into one policy.
I try to group policies based on a few different signals, such as:
- The type of user. Administrator accounts need stricter policies than regular users.
- The type of data. Access to Teams should be stricter compared to To-Do, which doesn’t contain as much confidential data.
- The ownership of the device used to access the data, as there’s a big difference between the management of personal and corporate devices.
- A personal device shouldn’t be trusted with as much data as a corporate device, which will have adequate security controls in place which will ensure data is protected.
- The ability to require different policies according to device ownership is a great use case.
If you wish to control all three of these signals, it’s not unusual to have ten or more different Conditional Access policies. However, I would recommend grouping them as much as possible to avoid the complexity that comes with managing many policies.
Documentation
As the number of active policies increases, documentation becomes increasingly important. Your documentation should include details of the configuration and a description of what the policy tries to do, which will help you revert the policy to the original state (if required following a change) and remind you why it was implemented in the first place. While it might not be necessary for smaller environments, this is absolutely a necessity for larger enterprises, especially if multiple engineers are responsible for the policies.
I often draw out the policies into a flowchart, as seen in Figure 1. This allows you to visually follow the login process of a user to determine whether they will receive access or not:
Besides documenting policies, be sure to document your exclusions. Not just what exclusions exist, but more importantly: who added the exclusions and why. This tactic helps as you review the exclusions regularly to decide whether they’re still necessary. For whatever reason, many companies don’t document these kinds of exclusions, nor the reasoning, which means no one dares clean them up because they’re afraid that removal will break something.
Aside from documentation, you can use Conditional Access as code. This means your Conditional Access Policies are saved as json files (code) and pushed through a CI/CD tool such as Azure DevOps or GitHub Actions. Changes are made to the source file, and only after approval will the script push the changes – this ensures all changes are peer reviewed which minimizes the margin for error. And as the policies are stored as code, you also ensure your original state is documented.
Read more: Using PowerShell to Manage Conditional Access (CA) Policies
Audit
While documenting your policies helps to revert policies to the original state after an unintentional change, it’s important to know what happens with your policies. Auditing the creation, updates, and removal of policies ensures you are always aware of their current state.
Conditional Access policies can have an extremely significant impact on an environment – just one mistake can affect users very quickly and you don’t want to be the first customer who locks all users out of the tenant. By default, every tenant has access to the Azure Active Directory audit logs, which allows you to search for any modification on your Conditional Access policies. In addition, you can export these logs to a Log Analytics workspace (optionally using Microsoft Sentinel) to setup alert rules to notify you when a change happens.
Besides monitoring policies, monitoring the groups used in the policies is a great idea. Organizations often use groups to scope policies, and an unwanted change to an exclusion group could create a significant hole within your environment.
Break The Glass Accounts
Conditional Access can be extremely powerful, but also dangerous because one small mistake in a policy can lock all users out of your tenant. An outage in the Azure AD MFA service could mean users are unable to access your tenant, therefore every Conditional Access policy should include at least one excluded account, the emergency or ‘Break Glass’ accounts.
These emergency accounts hold the global administrator role and are used to log into the tenant only during emergencies. Once administrators regain access to the tenant, they can make whatever changes are necessary to restore user access. An overview of best practices for emergency accounts is available here.
Use Conditional Access!
In my opinion, a tenant without functioning Conditional Access policies is an insecure tenant. Besides the benefits of implementing Multifactor Authentication in a smart, user-friendly way, Conditional Access policies have controls to limit what data users can access or download in certain scenarios, adding even more value. While getting started with Conditional Access policies can seem daunting at first, creating a solid design and documenting your policies will make things more manageable.
Hi,
I am new to conditional access, I have a few questions.
If there are no conditional access policies configured are users allowed to authenticate and login as long as they have been provided with correct login details.
If a conditional access policy is created with block all apps but exclude users from specific location and you don’t include an admin exclusion will you be locked out of tenant?
Does conditional access polices have an order of precedence?
I have heard of admins locking out all users from portal so just trying to get my head around logic.
Thanks
Yes that is correct, if you don’t have CA. It all goes out.
You can be locked out of a tenant yes, that’s why it’s recommended to have a break the glass account. cfr https://365bythijs.be/2020/02/10/best-practices-for-emergency-accounts/
For the order of CA, pleas see: https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-policies
Hi, I’d like to set it up strict conditional access, that would allow logging into M365 if it’s a domain joined Windows machine or Intune compliant device (macOS or iOS), otherwise block it. The goal here is to prevent staff to log into their M365 accounts from their personal computers.
From the template list, I’ve created a CA013.
Set it to all users group.
Applied to: All cloud Apps.
Conditions: Windows, macOS and iOS.
Grant: Require device to be marked as compliant & Require Hybrid Azure AD joined device & Require one of the selected controls
It’s on report-only mode now, but can you advise if it’s the correct policy configuration to accomplish my goal?
Thank you for the help.
Two things here:
– I would work with an include ‘all’ in Device platform and exclude specific platforms. This way, you also cover unknown/unsupported platforms. (Because not all platforms are listed here).
– This will also block sign-in through the web browser, is this desired?
Hi! Great article – I always love to hear other professionals and their take on handling CA – there are so many options depending on the scenarios.
I haven’t been able to find a good response yet to :
What happens if you do not choose any cloud apps or actions? Will the policy simply just not work because it lacks a signal to trigger it from any service connections of any kind? I see many customers try to avoid too many policies by NOT choosing to specify apps or user actions.
Hi Peter
It is necessary to at least choose one cloud app or action. If you don’t select anything, you won’t be able to save the policy.
I prefer to choose all cloud apps (and not specific them individually) as this ensures you have complete covering. Only if you have a specific use case for a specific app, does selecting specific apps make sense.
Hey Thijs,
i have a question which no blog, website or MS Doc could help me with. I want to restrict all not company owned devices from using an app which uses SAML through AzureAD. When i build the policy and choose only this one APP from the list of enterprise applications it is not working because its says: not applied – application not matched (not included). If i choose all cloud apps it is working AND it tells me that the application has matched… i have tried different applications but it only works if i choose all. I found an article with exact the same problemm but there where no answers…
Perhaps you have an ideo whould could be wrong 🙂
Hi Henry
How is the app added to AAD? Can you verify the App ID in the CA policy is the same you see in the Signin Logs?
Kind regards
Thijs
Hey Thijs,
thanks for your fast reply! The App is added to the tenant when you log in the first time. There is the question to log in as admin to allow this app in the tenant. I even removed it one time and added it again. The App ID in the Enterprise Application page and the sign in logs are the same! And i have 2 Apps where this behaviour is completely the same.
Greetings
Henry
Hey Thijs,
i tried some different things today. It seems that it is working the other way arroung. If i block ALL Cloud Apps and exclude this single App i can not login to Outlook365 BUT can login to this single app… The info in the conditonal access window is the same, the app did not match. Its kindly weird that it is only working this way or is it wanted from MS?!
Greetings Henry
It’s extremely hard to troubleshoot this over comments unfortunately. I would recommend to open a support ticket and verify.
Kind regards
Thijs
I think i got the “answer”. It looks like it is only possible to filter Microsofts Apps this way. Using the “Microsoft Office” App works perfectly fine. Exclude single “Third party Apps” from policies for alle cloud Apps is possible.
Great read, thank you.
How do you recommend implementing a requirement for MFA when connecting from the corporate IPs? We’re considering not requiring MFA from our IPs, but how will users complete the MFA enrollment when in the office.
Any pointers?
I require MFA configuration both corporate IPs or on compliant devices. This means they have the option to configure MFA outside of the office
With this CA policy enabled, would that mean that an administrator (as defined by the policy) would also have to use MFA when logging in to, say, office.com as well? Is there a way to only have this applicable to the admin portals (Azure, Exchange, SharePoint, User, etc)?
Yes, an admin would be triggered for every login, which is something that you want. MFA should be enabled for every app
In order to scope to certain portals, you need to select ‘Cloud Apps’ in your CA policy. Here you can find certain web portals, unfortunately not every admin portal has a cloud app. Which means you won’t be able to succeed in the use case you just mentioned.
Thank you! That’s what I figured but wanted to clarify. Great post!
How do I make sure users cannot download email, data from O365 when using personal devices and this default policy “ Require MFA for users when using non-corporate devices.” ?
Hi Sophia
This can be done by using the following configuration:
– Select ‘Office 365’ as the cloud app
– Select ‘All Platforms’ with an exclusion for Android/iOS
– As Client Apps ‘Mobile apps and desktop clients’
– Grant control: Require compliant device/HAADJ
Kind regards
Thijs
Thanks for this comment. Also working on implementing a “disable download from personal laptop” policy but cant seem to wrap my head around the grant control portion.
There should be two – using MDCA for browsers – https://practical365.com/using-microsoft-defender-for-cloud-apps-to-secure-access-for-remote-workers/
Another one for desktop applications (Mobile Apps condition) which require a compliant device
Useful article. Just a question regarding the break glass account: where’s the link to set up Diagnostic Settings?
This can be found here: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-integrate-activity-logs-with-log-analytics#send-logs-to-azure-monitor.
This allows you to stream your audit logs to Log Analytics and create alerting