Unboxing Microsoft Defender for Business, Part 4: Integration with MEM and Conditional Access

Back to Blog
Unboxing Microsoft Defender for Business: Device-based Conditional Access

Unboxing Microsoft Defender for Business, Part 4: Integration with MEM and Conditional Access

Welcome back to this series! Microsoft Defender for Business (MDB) is a huge product with lots of ground to cover. So far we have discussed the Simplified configuration process, Threat & Vulnerability Management, and Attack Surface Reduction Rules.

Since we began our series an exciting thing has happened: MDB has been released into the Microsoft 365 Business Premium SKU. This announcement was made along with another, which is related: General Availability of Microsoft 365 Lighthouse for partners (including some important announcements about GDAP). These are big steps forward for those of us who service SMB organizations in the Microsoft cloud.

But for today, we are going to return our focus to Microsoft Defender for Business and discuss how we can integrate signals from our EDR with Conditional Access. What this means is that we can leverage data from MDB to determine whether or not our endpoints are “healthy enough” to access corporate resources like email and files in Office 365. If the threat level is determined to be too high, then access can be rescinded until the device has been cleared of threats.

Step 1. Prepare MEM to integrate with MDB

Some of these items may already be switched on in your tenant, but it is a good idea to double-check, and get them set correctly if not. In Part 1 of this series, we already checked Endpoints > Advanced features in the Microsoft 365 Defender Settings area, so we should be good there. Next navigate to the Microsoft Endpoint Manager portal (https://endpoint.microsoft.com).

Integrate MDB with MEM

Go to Endpoint security then under Setup find Microsoft Defender for Endpoint. Switch every option to On if it isn’t already. Be sure to Save your selections on this screen.

Step 2. Configure compliance policies

Next we are going to visit Device compliance.

If you want users to receive a notification, then go to the Notifications page from the left navigation and add a notification that you can use with your compliance policy.

Add a notification for MDB

In this example I have named the notification: “Device is above acceptable risk threshold” with a simple message for the end user about contacting IT Support for immediate resolution. You should customize your own message to fit your situation.

Return to Compliance policies to create new policies: one for each device platform that you intend to support (unless you plan to cover mobile devices via MAM in which case you can skip those platforms for now).

Create a new compliance policy for MDB

Starting with Windows 10 and later devices, we will give this policy a name and description that makes sense. On the Compliance settings page, expand the Microsoft Defender for Endpoint option.

Configure the Defender for Endpoint setting

I have set this option to Clear in the above example, which means that device must be free of threats or it will be marked noncompliant. You can also choose Low, Medium, or High as the “risk score” threshold (by the way, selecting High would mean that any threat level keeps the device in a compliant state, so obviously this would not be recommended). Read more about how Defender ranks threat severity here.

On the Actions for noncompliance page you can decide whether to include a grace period (delay), and whether to include other actions such as Send email to end user (selecting the template you created above).

Set the Actions for noncompliance

Note: In my experience, sometimes a short grace period for Mark device noncompliant can be a good thing. For example, in the event of a false positive or something relatively simple that can be handled by Automated Investigation and Remediation (AIR), the device will return to Clear status on its own. 

Click through to Assignments and finish setting up your policy (consider starting with a pilot group and run them on this configuration for at least a week before moving to All users). Again, you can create a policy like this for every device platform that you intend to support.

Step 3. Configure App Protection Policies (optional)

For mobile devices, remember that we have two options: we can either enforce policies via MDM (full device-based management) or use a lightweight app-based management model (MAM). If you are taking advantage of this latter type of policy, then know it is also possible to integrate it with MDB’s threat status as well.

Recall that screen from step 1 (Endpoint security > Setup Defender for Endpoint); down toward the bottom of that page are the options to enable MAM integration for iOS and Android.

Double-check the MAM integration is enabled

Assuming these are on, then you can configure the corresponding settings in your MAM policies (Apps > App protection policies). Specifically, on the Conditional launch screen, you will want to scroll down to the Device conditions area, and configure the setting called Max allowed device threat level.

Configure Conditional launch settings

In this example I want it to behave similarly to my device-based compliance policies, so I will choose “Secured” (which is the same as Clear in the compliance policies), and set the Action to Block access.

Step 4. Configure Conditional Access

Before you deploy a Conditional Access policy to enforce the new compliance requirements, you should be sure that the users and devices you have targeted are showing up as compliant in the Microsoft Endpoint Manager portal. As well, users should have the Company portal app and the Defender app installed on their mobile devices.

Verify device compliance

Once you know for certain that your devices are reporting in and compliant (and therefore unlikely to be negatively impacted by a device-based CA policy), then you can proceed to the final step.

When you’re ready, navigate to Endpoint security > Conditional Access. Create a new policy and give it an appropriate name. Target the same (licensed) users that you did with the compliance policies and app protection policies in the previous steps (and always be sure to exclude at least one emergency access account). Under Cloud apps or actions, select just one cloud app for now: Office 365.

Create your conditional access policy for MDB integration

Under Access controls > Grant, select Require device to be marked as compliant as well as Require app protection policy. Then down below use the option Require one of the selected controls. This means that access to Office 365 will only be granted if the device can satisfy the requirements of the device-based compliance policies (clear of threats), or the app-based protection policies (which require mobile devices to be clear of threats).

Note: As regards other Conditions in the policy, this is dependent on your situation. For example, do you want to apply this access control only for Mobile apps and desktop clients, or do you want it to apply to access requests that take place via web browsers also? You could also construct this as two policies, with one targeting just iOS and Android devices with the App protection requirement, and another for Windows/macOS that enforces compliance. The policy I show here just does both in one with no additional conditions.

You can Create and enable the policy to finish.

Conclusion

At this point, when a user who is in the scope of these policies winds up in a situation where one of their devices is compromised by some threat according to MDB, then access to Office 365 will be suspended until the device can be remediated.

In some cases this happens automatically due to Automated Investigation and Remediation (AIR should be on by default in MDB) or because of a temporary false positive. In other cases there may be serious follow-up required, and it may even be best to Autopilot reset or factory reset an infected device and then run scans across other devices to restore confidence in the environment.

But at the end of the day, now you have a solution that you can take to your customers that is unlike any other you’ve had before: when Defender’s telemetry determines a device may be at risk, then your user will be alerted, and access to corporate data and resources can be automatically rescinded if the threat is unresolved within a very short period. This reduces “dwell time” and lowers your overall risk. That’s a pretty compelling statement, I think.

Now, one last note: Microsoft has not released the “standalone” version of MDB at this point (just the one bundled in Microsoft 365 Business Premium). I do not expect this feature to be included with standalone, since it requires additional licensing such as Azure AD Premium P1 and Microsoft Intune/Endpoint Manager (both of which are found in Business Premium). So keep that in mind in case it applies to your situation.

Cheers. Until next time!

Comments (8)

  • Rob Stott Reply

    Any idea why I wouldn’t be able to find Automated Investigation and Remediation options in my tenant? I don’t have “Automatically resolve alerts” toggle in my settings.

    March 10, 2022 at 7:39 am
    • Alex Fields Reply

      Unsure, I do see the option and AIR is set to On by default for MDB. But if you’re not seeing it, I do not know the cause. Do you have the MDB licensing assigned in your tenant? I think folks who are on MDE P1 may have a partial set of options; you see more once you upgrade to MDB, and then all of the options of course will light up with P2.

      March 15, 2022 at 3:10 pm
  • Tracy Ratz Reply

    Does the Android app need to be configured? I setup my MAM policy for Android, but when I sign in to my O365 account from an android device, it tells me the app isn’t configured. With MAM, I am not enrolled, but do I have to enroll the device with MDM and set the configuration on the device in order to use Android. I didn’t have to do anything for IOS devices.

    March 15, 2022 at 1:44 pm
    • Alex Fields Reply

      This is sort of dumb, but how it works on Android is slightly different than iOS. In the Apple line, when MAM policies are applied, it needs to register the device with the service and it does this using the bits from the Authenticator app. So if you have that installed then you’re good to go. But with Android, it needs to lean on bits in the Company portal app. So what confuses some people is that they think they have to use Company Portal to enroll the device, but that’s not true. All you have to do is have Company Portal installed, and when you get the MAM policy applied and it goes to register and restart the app it leans on the portal app temporarily to complete that one-time registration step. So dumb.

      March 15, 2022 at 2:31 pm
    • Alex Fields Reply

      Oh gotcha, yes this Docs article has the “setup steps” for Android (both Device administrator and Enterprise).

      March 15, 2022 at 2:49 pm
  • Tracy Ratz Reply

    Alex:

    That part I understand. What is not happening is that the defender app comes up with an error saying app disabled by administrator and that the defender for endpoint security and tunnel vpn features are disabled. All of the other apps are working fine. Is there something I am missing because with the IOS version of Defender it is working perfectly fine.

    March 15, 2022 at 2:45 pm
  • David Reply

    Same here – Did you get this working?

    April 13, 2022 at 1:45 am
  • Tracy Ratz Reply

    I did get it working. I had to go under connectors in endpoint manager and check from that page as my tenant while on the endpoint security page had MAM enabled, on the connectors it wasn’t. Once I gave it a half hour, everything started working. For the android tablets that already had it loaded, we had to take out and even the office 365 account on the phone to reset it and then everything worked as expected.

    April 13, 2022 at 7:24 am

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.