Have you ever deployed a Conditional Access policy, only to later discover that users had found a way to circumvent it? It is surprising to discover that someone found a way around your carefully designed and tested policy.
Setting up Conditional Access policies can get confusing. If you don’t plan your policies carefully, you may end up with holes that you didn’t expect. Most of us start by thinking about the scenarios we want to allow. The problem with this approach is that if you only think about what you want to allow you may forget to block scenarios you don’t approve. Without a policy in place to block unapproved scenarios, a malicious actor can exploit those scenarios by simply providing a user’s compromised credentials.
For example, consider this scenario: You are asked to create a policy that will allow a user to access their email on an iPhone. You will allow a user to use the native mail application with ActiveSync or Outlook if the application is protected by a Mobile Application Management policy. The policy you create is applied to the user, targeted to Exchange Online, and applies to ActiveSync and Modern Authentication clients. Controls are set to grant access if the device is compliant or if a MAM policy is applied. When you test the policy and the device is not registered you are blocked from accessing the application in the ActiveSync client. The Outlook application prompts you to install the Azure Authenticator to access the application. Once the Authenticator app is installed or it is enrolled the user can access their mail in the targeted applications. This policy works as designed; users must meet one of the controls in the policy to use their email as intended. You may consider the policy successful and move it into production. However, there’s just one problem… When a conditional access policy is in place all conditions must be met before the access controls are evaluated. If you had tested other scenarios that you expect should fail, you would have found that in this case the user could access their email from the device’s browser – even if it is not enrolled in Intune. The policy would have been evaluated as follows:
The controls to grant access are not evaluated because the policy doesn’t apply to browser access on iOS devices. Sign-in is allowed. If this user’s credentials are compromised and no other controls are in place, a malicious actor would be able to access the mailbox. Since the browser is also not being managed through Intune this represents a significant data leakage risk.
Any scenario that has a policy applied to it will block access if the conditions are not met. Scenarios that do not have any policy applied will allow access to anyone with a valid credential. We can prevent users from accessing services by using a second policy with the block access control. In this instance we could successfully block access from unapproved scenarios with a policy that applies to Exchange Online on iOS devices. We would include a condition that would target the browser and other client applications. The control would be set to block. That policy would be evaluated as follows:
A proper Conditional Access deployment needs to consider scenarios that should always be blocked. As policies get more complex, it can become more difficult to determine if you have accounted for all possible scenarios. Intune and the new Modern Endpoint Manager Admin Center have a built in What If tool that lets you walk through a range of possible scenarios to see how your policies will be evaluated.
To demonstrate this tool, I will use a more complex example. In this case we want to create a policy that will apply to both iOS and Android devices. iOS devices can use Exchange ActiveSync if they are Intune Compliant. Users should be able to access their mail through the browser on compliant mobile devices. We want to allow Outlook mobile on any iOS or Android device whether it is enrolled or not. There is a Mobile Application Management policy in place. ActiveSync should be blocked on Android devices. We also want to block access from other email clients in all scenarios.
We will use 4 policies to accomplish this goal:
In a future blog post I may create a walkthrough on how I created these policies. You can find more information on configuring Conditional Access here.
You can access the What If tool on the Conditional Access blade by clicking on the button on the page ribbon.
The What If tool has fields that allow you to build a scenario to test. You can select a user, application, IP Address, Country, device platform and state, client app, and Sign In risk.
I want to test whether I will be able to access Exchange Online from my enrolled iPhone through the Outlook application. To test this scenario, select the appropriate settings and click the blue What If button.
When you click on the button the evaluation results of your scenario will appear below. There are two different tabs – Policies that will apply and Policies that will not apply. The policies that will apply shows any policies that will apply and the controls that will be applied to your device. In this case the Enrolled Mobile Device Policy will apply with access being granted because the device is compliant.
The policies that will not apply tab shows all the policies in your tenant that will not apply. It also shows the reason the policy will not apply. This is helpful because you may have a policy you expected to apply but did not. You can easily edit a policy within the tool and re-evaluate it.
If we were to change the above scenario to test on an Android device, we expect that access will be blocked. We can see that two different policies were applied: Enrolled Mobile Device Policy and Block EAS on Android. The first policy would grant access, but the second policy explicitly blocks access. When using Conditional Access, a block condition will always take precedence over an allow condition.
If we wanted to edit a policy because of unexpected or undesirable results, we can click on the policy here to edit it. Clicking on a policy will open an editor flyout on the right side of the page. Here you can make changes and save a policy without having to leave the What If tool.
After you save changes the policy will be re-evaluated. Any changes made will be reflected on the Evaluation results.
To effectively use the What If tool, make sure to test all the possible scenarios for the device and application you are targeting. This will ensure that all scenarios are accounted for. It is much quicker than doing it manually and waiting for a device to download updated policies. This will streamline your testing process and help you to build better policies.
Properly built Conditional Access policies are one of the most important tools to protect corporate resources accessed through Azure and Office 365. Taking the time to plan your policies and thoroughly test them is essential. The What If tool gives you the peace of mind to know that you have built the best possible policy set for your environment.