One of the nice features of Intune (and to a greater extent, Azure Active Directory), is the ability to apply Conditional access rules against your clients, to ensure they are only accessing the resources they should be accessing, and only on the devices and locations they need to be.
What is Condition Access?
Conditional Access is the ability to restrict who, what, where, why and how, your Users and devices are accessing your organizational resources. For example: Let’s say you only want users who’s devices are Managed by Intune to be able to access any Office 365 resource. You can easily define a rule that only allows those users and devices to access that.
How can I define a Conditional Access Rule?
There are 2 places you can define a Conditional Access rule in Azure. You can access them 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 then name it. (For this example, I called my Rule “Conditional Access Policy. Very creative, right?)
As you can see in the picture above, there 2 Main Sections, “Assignments” (The Who, What, When, and Where of the Policy), and “Access Controls” (The Why and the How of the Policy). These 2 Main Sections are divided up into Subsections. Each of these will be covered next.
Users and Groups
This is pretty self- explanatory, as this is the “Who” portion of the policy. What Users or Groups should this policy be applied to, or conversely, who should be excluded from receiving this policy:
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 don;t meet the rules requirements? Natively, this option will include (or Exclude) all of the major Office 365 Applications (Exchange, SharePoint, Groups, Teams, etc.), but it will also allow you to restrict any Cloud Apps that have been connected through Azure Active Directory:
Conditions
This is the Where/When portion of the policy. From this setting we can define the following Sub-Sub-Sections:
Device Platforms
Do you want this poliocy to only apply to Android Devices? What about just devices running Windows? From this section you can include/exclude Android Devices, iOS devices, Windows Phone Devices (HAHAHAHAHA) or macOS devices.
Locations
If your users are located on the local Intranet, is conditional access something they really need to have applied to them? If your’re not worried about devices inside of your firewall, you can use this setting to include/exclude devices that come from trusted IP addresses.
Client Apps
Maybe you’re only interested in restricting access to Devices who accessing resources from a Browser. Or maybe only devices who are using Mobile or Desktop apps. From this screen, you can define the type of application the 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 the Native iOS or Android Mail Applications)
Grant
This is the Why/How portion of our policy. Are you Granting Access or Blocking access? Do your users need to go through MFA first? If they are devices 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 won’t go into further detail on this option as it is still in preview and not well defined of fully featured yet.
In Conclusion
As you can see, Conditional Access rules are very easy to setup 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. If you’d like to learn more about Conditional Access, Azure Active Directory, or Intune, please feel free to reach out to me at jo.karnes@centricconsulting.com