A framework for implementing device-based Conditional access with Microsoft Intune

I recently shared a set of scripts to help make deployment of Intune a bit quicker. Today I just want to cover a framework which can be used for deploying device-based conditional access in conjunction with your baseline policy set.

The main crux of the issue, which I have seen a lot as I consult with organizations who are wrestling with learning these new management tools, is that you cannot just “turn stuff on” blindly and push down all of your settings across all devices at once. There is a method to the madness.

An example of doing it wrong

Take for instance the following situation:

An admin stands up some policies either manually or using some scripts, and then proceeds to enroll devices. So far, so good. Next, the admin goes to turn on Conditional access, and suddenly half the users are locked out of their resources. Why?

Most likely, the admin did not verify any of their initial steps. You see, when you define a compliance policy, that will become “the bar” for gaining access to company resources when you enable a corresponding conditional access policy (the access control is called Require device to be marked as compliant). So be sure your devices are in fact marked as compliant.

If your compliance policy requires BitLocker or SecureBoot, for instance, then you better be sure all the devices that you have enrolled out there have the right settings turned on, before you go enabling conditional access. Device-based access controls are much different than say, requiring multifactor. Your device-based policies are going to require you to pay more attention to what’s out there.

Device-based Conditional access: the proper roll-out methodology

Now let’s take a look at the right way to implement this.

The two steps highlighted in red above are the ones I most frequently see skipped (to the shame of many an admin). After you implement a compliance policy, and enroll devices, it is always always ALWAYS in your best interest to go review the results of applying said policy.

This is easy to do, just go click on Device compliance in the portal, and find the Device compliance view under Monitor.

Hooray for me! No non-compliant devices–which indicates to me that proceeding with a Conditional access policy is safe. If you have devices which do not meet compliance, however, then you need to dig in further.

You can get another good view simply by clicking on a compliance policy.

On the device itself also, you can drill into Device compliance, to see which settings are having issues applying, and which are successful. Find a device, click Device compliance under Montior.

Select the policy to see corresponding details.

If there were an issue with any of these settings it would have a red circle with an X instead of these green check marks we see here. Then you would know for each device precisely what needs to be looked at before proceeding to implement Conditional access (which is always the last step).

Making changes to existing compliance policies

Now consider the following. All the devices have already been on-boarded into existing compliance policies. But maybe you want to improve the policy. Say that you did not start out by requiring BitLocker but now you would like to include that in your compliance check.

Again, you might end up in the same situation we described before if you simply edit the existing compliance policy and tick the box for encryption. After all, if you are already requiring device compliance, changing the requirements for “compliant” vs. non-compliant may have an impact on a user’s ability to access resources.

Therefore, you will want to have some way of vetting in advance who may or may not fail compliance before you make a change. One way to do this might be to leverage device configuration profiles. Push out the settings you want devices to have, and then after you have verified the successful roll out of a configuration change against enrolled devices, raise the bar within your compliance policy (again, as the last step). We will discuss the process for rolling out configuration profiles next time.

Some settings, such as SecureBoot, may not be possible to configure using device configuration profiles, or indeed any function within Intune. The key piece that you need to take away here is that compliance policies can, when combined with Conditional access, impact user experience. So be mindful when you go to roll it out, and whenever you make changes to it down the road.

Hopefully this information saves you a headache or two as you go to implement these policies for your own end-users and customers. Again, soon we’ll look at implementing device configuration profiles. Those require a slightly different approach–stay tuned.