Microsoft Intune, Part 1:
Controlling Access to Microsoft 365 Data
Microsoft Intune was introduced back in 2011. Over time, it has proven to be a strong player in the world of device management—especially in these difficult times where end-users are increasingly working remote from their offices and organizations are seeing increased use of personal devices. This blog series will go through some capabilities of this product and explain how organizations can take advantage of the security features it offers.
This first post in a three-part series on device management with Microsoft 365 provides a prequel of what is necessary before entering the world of device and application management for iOS (and other mobile device platforms).
Intune – Deploy & Manage Apps
Intune gives you the ability to deploy apps to end-users by adding them to the Intune portal. Administrators decide which group (or groups) of users has each app available to them. Intune can also push an app to a device, regardless of whether the user wishes to receive it or not.
Before leveraging this solution, however, it’s necessary to make sure all devices that try to access the Microsoft 365 data are in fact permitted to do so. It is therefore necessary to implement Conditional Access (CA) policies to control who and what can access the data, and from where—even specifying what times and using what application on which approved devices. Intune and CA work closely together but are separate components within Microsoft 365 and do generally different things.
Conditional Access
Within a given tenant, Microsoft 365 services and data are available to anyone with a valid username and password from anywhere in the world using any device. Administrators wishing to control this are required to implement additional security. The bare minimum license to implement this is the Azure AD P1 license. But corporations typically go one step further and apply Enterprise Mobility & Security: “EMS” licenses. We won’t go further into the licensing options. Safe to say, the choices are varied depending on the level of functionality required.
Conditional Access permits administrators to control which users, devices, and categories of applications that can (and cannot) access Microsoft 365 data. Let’s take a look at some of the possibilities, particularly around how to ensure users enroll their devices in Intune, starting with where administrators can find Conditional Access.
Taking a look at legacy application and protocol access: administrators will only want to allow users to connect using applications that support legacy access. As shown below, a simple policy will ensure that any user using any device with an older application will be blocked from accessing data.
Some legacy systems may have to connect to the environment. So, in addition to the groups you select to enforce the policy against, you may also specify users or groups who may bypass this policy.
The next policy is to enforce multi-factor authentication. It is true that you can implement MFA at the user level elsewhere in the administrative portal. However, Conditional Access allows you to implement this at the group level—not available as an option in the other location. If necessary, exceptions can be made for certain users—for example, MFA might be bypassed for a specific user if a particular application is being used.
However, the main policy here is the one that dovetails with Intune. Here, we create a policy where any connecting device must be compliant—without having to define here and now what constitutes compliance.
Administrators must be careful not to lock people out, so although this is the first of three articles, the first two should be read together. The 2nd article discusses making policies to define device compliance. Create the policies for devices, and then—when you’re sure users are accessing the data from acceptably secured devices—you can go further and fully implement the Conditional Access portion.
With this policy, you can go to town selecting which users are affected, which Operating Systems are acceptable, merge the MFA requirement into the policy, and define whether the device and user must meet one or all of the access parameters.
If you do implement something that might potentially lock yourself out of the CA, the policy-creation wizard will warn you in advance and give you the option to: leave the policy in an Off state, accept the policy, or exclude the currently logged-on administrator from the policy. Ample testing on pilot users and devices should be performed first, as well as careful planning of the devices, applications, and other restrictions before rolling out to the wider organization.
Unwanted Visitors
In addition to Microsoft 365 being able to alert you to risky logins and subsequent login attempts from ‘impossible’ locations (e.g., a login from Philadelphia at 1pm and a login from Madrid at 2pm), whole areas can be excluded from access. The first thing to do is define those locations (as per the image below).
Once the banned locations are defined, they can be worked into a policy (as shown in the image below).
As before, exceptions may be implemented. If access from a specific country is unacceptable, but personnel are on legitimate travel to that country, exceptions can be made. You still want to specify that the devices being used must be compliant and that MFA is enforced.
To Recap
Implementing Intune is only the first step in securing your environment from unwanted intrusion by untrusted devices and locations. Given the predominantly remote nature of today’s workforce, controlling which users and devices can access the environment—and from where—is more important than ever. Conditional Access policies permit the administrator to implement comprehensive controls on data access.
Up Next
This first post on a three-part series explains how to ensure data is accessed from managed devices that are controlled, how to make a device “compliant,” and how to wipe a device when necessary. Part two explains the steps administrators use to ensure users wielding devices are doing so in a managed way—even if the devices are owned by the end user rather than by the company itself. Lastly, if you have any questions about maintaining device compliance, or any other aspect of device management, please don’t hesitate to reach out to us. We’d love to help ensure your security.
Share on 
