Conditional access helps keep your data safe by restricting who, what, where, why, and how users and devices access organizational resources.
Part three of a series.
One of the nice features of Intune (and to a greater extent, Azure Active Directory), is the ability to apply conditional access rules to ensure users only access the resources you want them to on the devices and locations you have approved.
What is Conditional Access?
Conditional Access is the ability to restrict who, what, where, why, and how your users and devices are accessing your organizational resources.
Let’s say you only want users whose devices are managed by Intune to be able to access any Office 365 resource. You can easily define a rule for that.
How can I define a Conditional Access Rule?
There are two places where you can define a “Conditional Access” rule in Azure.
# 1 – You can access it through the Azure Active Directory Blade, or the Intune Blade.
For this example, I just accessed Conditional Access through the Intune Blade. Our first step will be to create a new “Rule” and name it. (I called my rule “Conditional Access Policy.” Very creative, right?)
As you can see in the picture above, there two main sections, “Assignments” (this is the who, what, when, and where of the policy), and “Access Controls” (the why and how of the policy). These two main sections are divided up into subsections.
Each of these will be covered next:
Users and Groups
This section is pretty self-explanatory, as this is the “who” portion of the policy.
What users or groups should this policy be applied to? Or, who should be excluded from receiving this policy? See below:
Cloud Apps
This is the “what” portion of the conditional access policy.
What cloud applications are you trying to restrict users from accessing if they do not meet requirements outlined in the rules? Natively, this option will include (or exclude) all of the major Office 365 applications (Exchange, SharePoint, Groups, Teams…).
But it will also allow you to restrict any cloud apps that have been connected through Azure Active Directory:
Conditions
This is the where and when a portion of the policy. From this setting we can define the following sub-sections:
Device Platforms
Do you want this policy to only apply to Android devices? What about just devices running Windows?
From this section, you can include and exclude Android devices, iOS devices, Windows devices or Mac devices.
Locations
If your users are located on the local Intranet, is conditional access something they really need to have applied to them?
Also, if you are not worried about devices inside of your firewall, you can use this setting to include or exclude devices that come from trusted IP addresses.
Client Apps
Maybe you are only interested in restricting access to devices accessing resources from a browser. Or maybe only devices using mobile or desktop apps.
From this screen, you can define the type of application that users are restricted from using:
(NOTE: In the screenshot above, you will notice the blue banner notifying us that “Legacy auth is currently not supported.” This applies to apps like Native iOS or Android Mail.)
Grant
This is the why and how portion of our policy.
Are you granting or blocking access? Do your users need to go through MFA first? If the devices are managed by Intune, do they need to be compliant in the Intune portal first?
You can define those options in this section:
Session
The session control is currently in preview, and currently only applies to SharePoint Online. I will not go into further detail on this option as it is still in preview and not well-defined or fully featured yet.
Conclusion
As you can see, conditional access rules are very easy to set up and deploy to your organization. Of course, I always recommend testing your rules with a limited group of users before rolling them out to your entire organization.
