Use Azure AD Conditional Access to Enforce MFA on Unmanaged Devices

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, which I demonstrated here so I will not cover that again in this article.

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.