Microsoft provides some different options for securing Office 365 and Azure applications with multi-factor authentication (MFA). For your end users you can choose from:
MFA for Office 365, which provides basic MFA functionality for Office 365 applications only.
Azure MFA, which provides more advanced functionality, including the option to configure trusted IPs.
The trusted IP feature is attractive because it allows you to define IP address ranges, such as those of your corporate network, from which you will “trust” the logins and not prompt for MFA codes. This is useful for decreasing the annoyance factor of MFA for your end users, but doesn’t solve the problem for all types of organizations. For example, a staff of roaming sales people will frequently be accessing their applications from outside the corporate network, which will cause them to be repeatedly prompted for MFA codes. Yes there are some apps where you can “remember” the device and avoid repeated prompts, but not all apps provide that. App passwords, which are separate passwords for a user that bypass MFA, are also not practical in all cases as they become difficult to manage over time.
For some customers it’s not just a subset of their users, such as the sales staff, that access apps from “outside” the corporate network. It’s becoming more common for the concept of a corporate network to not exist at all for a company. And even for those that can define a network boundary that traditionally would separate “inside” from “outside”, it’s somewhat of a dated concept. Google’s “BeyondCorp” whitepaper explores this in more detail.
The goal of Google’s BeyondCorp initiative is to improve our security with regard to how employees and devices access internal applications. Unlike the conventional perimeter security model, BeyondCorp doesn’t gate access to services and tools based on a user’s physical location or the originating network; instead, access policies are based on information about a device, its state, and its associated user. BeyondCorp considers both internal networks and external networks to be completely untrusted, and gates access to applications by dynamically asserting and enforcing levels, or “tiers,” of access.
Looking at securing Office 365 access in that context, we can shift our thinking from using trusted IPs to avoid MFA prompts, and use signals about the devices and users. For this article I’m going to focus on the device aspect of the picture.
The devices that users connect from are either managed or unmanaged. A managed device is secured by way of being domain joined, or by being enrolled in Intune, which provides the organization with visibility of what is running on the machine, whether it complies with our security requirements, and so on. Put simply, you can tell whether the user is connecting from a rooted Android phone that is riddled with pirated apps containing malicious code, or whether they’re connecting from a Windows 10 laptop appropriate security settings applied.
Unmanaged devices are those such as home computers where the user might use their web browser to check email, or a mobile device that is not enrolled in Intune.
For this example scenario we’re going to achieve the following outcomes:
Users of managed devices of any platform are not required to use MFA, on the basis that they are secured and managed by way of being either domain joined or Intune enrolled. This effectively means that corporate owned devices, and BYOD devices that have been Intune enrolled, will not require MFA when the user logs on to Office 365 applications.
Users of unmanaged devices of any platform will be prompted for MFA when the user logs on to Office 365 applications. We can further secure access from unmanaged devices by using Intune MAM policies.
Both of those outcomes can be achieved with a single Azure Active Directory conditional access policy. Only one policy is required because there is no difference in how trusted and untrusted IP addresses are being treated. That said, you could define multiple policies if you needed to break them up for separate device platforms, different sets of users, or different Office 365 applications. For this demonstration a single policy is used.
To create the policy go to the Azure portal and navigate to Azure Active Directory, then choose Conditional Access.
Create a new policy and give it a meaningful name. Configure the assignments for the policy. I’m targeting this policy at the users in my tenant who are licensed for Azure AD Premium, which is required for conditional access. Azure AD Premium is available as a standalone license add-on, or it’s included in the Enterprise Mobility + Security (EMS) bundles. As a side note, if you’re testing any policy that might restrict access to Office 365 or Azure services you can exclude your admin account as a precaution against locking yourself out of all applications and portals by accident. Also, do keep in mind that if you do not target this policy at a user, they’ll be able to login without MFA from any device. Targeting “All users” may be the right approach for your organization.
Next, select the cloud apps that the policy will apply to. Again as a precaution, Microsoft recommends in their best practices doc that you avoid policies that apply to all user and all apps and require specific conditions that might result in completely locking yourself out of Office 365 and Azure.
For the conditions, I’ve chosen all platforms, all locations (no exception for trusted IP addresses), and all client apps.
Finally, set the access controls. This policy will grant access if any of the following conditions are met:
The user successfully provides an MFA code (the user must be enabled for MFA, and if they haven’t set up their code yet will be prompted to do so)
The user is logging in from a device that is marked as compliant (which means it must be enrolled in Intune first and meet the requirements of the compliance policy)
The user is logging in from a domain joined device.
Enable the policy and save it. Conditional access policies usually apply quickly but in some of my testing I’ve had to wait more than an hour to see the results.
A simple way to test the policy is to log in to the Office 365 portal, and then try to access one of the applications that the policy applies to (such as opening their Exchange Online mailbox in OWA). Note that prior to August 9th 2017 the Office 365 portal itself is not protected by conditional access policies, so the user will not be prompted for an MFA code. After August 9th the Office 365 portal will be subject to conditional access policies that you configure. If the user is on a domain joined device, or an Intune enrolled and compliant device, they’ll be able to access the application successfully. Intune enrollment requires an Intune license for the user, which is available as a standalone license add-on or as part of the EMS bundle. If they are on an unmanaged device, the MFA prompt will be displayed instead.
This provides the user with a choice. They can live with the MFA prompts when logging in from their BYOD or personal devices, or they can enrol the devices for management by Intune. It’s up to the user to decide which option strikes a balance between convenience (fewer MFA prompts) and privacy (some users don’t like their employer having “control” of their personal devices).
For this managed vs unmanaged device scenario you can also further secure the unmanaged device access by configuring Intune MAM policies to control such things as copying of corporate data to unmanaged apps (e.g. from a user’s corporate OneDrive to their personal Dropbox). You can also look at Azure AD Identity Protection to detect and block high risk logins.