Lower-Touch Defender for Endpoint Onboarding for Android Devices

Onboarding corporate mobile devices managed by Intune into Defender for Endpoint shouldn’t require your end users to do anything, and with supervised iOS/iPadOS devices this is exactly the case with Microsoft providing great documentation on the process and corresponding configuration profiles to support silent onboarding.

The same however can’t be said for Android Enterprise devices, even with the feature for low-touch onboarding currently in preview now Generally Available.

Although low-touch onboarding reduces the amount of hoops a user has to jump through, it doesn’t remove them all.

Can we help with that?

1 Defender App

First off, before we go configuring devices with their Microsoft Defender for Endpoint onboarding settings, we actually need our devices to have the app itself.

So go and add the app following along with Microsoft nicely.

Once added to your Intune tenant, you’re going to need to deploy it, with a Required assignment target.

Good, your devices have the app, but what about the configuration.

2 Low-Touch Onboarding

To configure low-touch onboarding, we need to configure two main things on the Android Enterprise devices:

1. The Defender App to give the app permissions and configuration settings
2. A loopback VPN profile to allow for enabling Web Protection

We’ll expand a bit more on some of the other permission and configurations you can apply, but for now we’ll just deal with onboarding the Microsoft way.

2.1 App Configuration Policy

If you skipped ahead when following the Microsoft article about deploying the Android Enterprise App, you may have noticed the section from Step 9 about App Configuration policies.

We’ll need one of these to turn on or off Defender App settings, or at least be definite with our choices instead of relying on the defaults.

To make sure that the Defender App is actually doing something, go ahead and configure a new policy with the below Configuration Settings.

With these basic settings we can at least ensure that the Defender App on the Android Enterprise device will be ready for onboarding.

2.2 Always-on VPN Profile

As we’ve configured the Defender app with the VPN setting, we need to deploy one to our Android Enterprise devices. This VPN isn’t really giving your devices access to anything, but is required to support the Web Protection functionality.

Defender for Endpoint on Android would use a VPN in order to provide the Web Protection feature. This VPN is not a regular VPN. Instead, it’s a local/self-looping VPN that does not take traffic outside the device.

We can easily create a new Device Restriction configuration profile (please can Settings Catalog come to Android Enterprise 🙏) based on the information in the Learn article, but save you clicking away, here are the settings required:

The Package ID of com.microsoft.scmx is the Defender for Endpoint Android app, we’ll need this later on.

With the VPN in place, we can now look at the specific Low-Touch onboarding settings.

2.3 Low-Touch Onboarding Settings

If we just configure the above, a user will still need to approve the permissions the Defender App is requesting.

We’ve dealt with the VPN, but it’s still going to ask for the following permissions:

• File Access
• Location Access
• Permanent Protection
• Accessibility
• Display over other apps

Now for all Android Enterprise device types we can only make this onboarding a little easier with Intune, by updating our App Configuration policy for Defender to include the below permissions and settings.

2.3.1 App Settings

These settings allow for the configuration of the low-touch onboarding approach:

2.3.2 App Permissions

To make the onboarding process a little smoother, we can give the Defender app some of the permissions it’s asking for, so again update your App Configuration policy and add in the below permissions.

This now means that users now won’t be prompted for three of the six permissions the greedy Defender app is requesting.

Can we sort out the remaining permissions though?

3 Lower-Touch Onboarding

The answer is maybe, and only if you have Samsung Android Enterprise devices running at least Android 13.

If a special permission is granted through the policy, the device doesn’t request the permission from the device user.

What started me on this journey was a post about the changes to the Shared Device mode for Android Enterprise on Samsung devices detailing how to use the Knox Service Plugin and an OEMConfig profile in Intune to give Microsoft Launcher overlay, or display over other app permissions on-behalf of a user.

Surely we can do the same for Defender on our supported Samsung devices?

3.1 Knox Service Plugin OEMConfig

Before we dive into attempting to configure these additional permissions for our users, we need an OEMConfig App available in Intune. So go an approve the Knox Service Plugin from the Managed Google Play Store.

Once available in Intune, I strongly suggest deploying this to all your Samsung Android Enterprise devices as the app is required before the configuration will apply.

Use a Device Filter with a rule looking like the below for your assignment:

(device.deviceOwnership -eq "Corporate") and (device.manufacturer -eq "samsung")

Once the app has installed, we can now move onto configuring a profile.

From my experience with OEMConfig profiles there can be only one assigned per Samsung device (Zebra devices are different), so if you’re already applying a Knox Service Plugin based profile, you’re going to have to amend that one instead of creating a new one.

Either way, to setup the Android Enterprise profile, if you need to create a new one, and to configure the required Defender for Endpoint settings:

• Navigate to the Microsoft Intune admin center and select Configuration under Manage devices, create a new policy for the Android Enterprise platform of type OEMConfig.
  • Give the profile a suitable name and a description if you’d like e.g., MVE-AND-AE-D-CO-KSP-Defender
  • Select Knox Service Plugin as the OEMConfig app
  • Select Next to continue to the configuration page
• Under Knox Service Plugin enter in a name for the Knox profile i.e., DefenderforEndpoint(1.0)
• Under Knox Service Plugin select Configure for Device-wide policies (Selectively applicable to Fully Manage Device (DO) or Work Profile-on company owned devices (WP-C mode as noted)
  • Under Device-wide policies set Enable device policy controls to true to enable it.
  • Select Configure for Application management policies
    • Under Application management policies set Enable application management controls to true to enable it.
    • In Battery optimization allowlist enter in com.microsoft.scmx
    • Under Application management policies set Enable permission controls to true to enable it.
• Under Knox Service Plugin select Configure for Permission Controls
  • Select the ellipsis (…) that’s next to Permission Controls and select Add Setting
  • Under Permission Configuration select the Permission Policy dropdown
    • Select Appear on top and All files access
    • For Package or Component Name, add the Defender app package name com.microsoft.scmx

This process should look something like the below:

The settings look like the this when all together in a nice table:

We’re setting Debug Mode to true for now, as we want to see the outcome of the application of the profile in the Knox Service Plugin app on the device, once happy that it’s working we change this to false.

3.2 Moto OEMConfig

Thanks to deweez in the comments, it looks as though the settings created for Samsung Knox devices, also work with the Motorola devices supported by Moto OEMConfig.

After adding the Moto OEMConfig app to your Intune tenant using Managed Google Play:

• Navigate to the Microsoft Intune admin center and select Configuration under Manage devices, create a new policy for the Android Enterprise platform of type OEMConfig.
  • Give the profile a suitable name and a description if you’d like e.g., ODD-AND-AE-D-CO-MOTO-Defender
  • Select Moto OEMConfig as the OEMConfig app
  • Select Next to continue to the configuration page
• Under Moto OEMConfig select Configure for Debug tools policies
  • Under Debug tools policies select Configure for Debug mode
    • Under Debug mode set Allow debug mode to true to enable it.
    • Select Configure for Application management policies
• Under Moto OEMConfig select Configure for System policies
  • Under System policies select Configure for Battery non-optimized apps
    • Under Battery non-optimized apps set Allow non-battery optimized applications to true to enable it.
    • In Non-battery optimized application list enter in com.microsoft.scmx
  • Under System policies select Configure for Display over the other apps settings
    • Under Display over the other apps settings set Enable display over the other apps to true to enable it.
    • In Display Over The Other Apps list select Configure
    • Select the ellipsis (…) that’s next to Display Over The Other Apps list and select Add Setting
    • Under Applications that require permission to display over the other apps in App package name enter in com.microsoft.scmx
  • Under System policies select Configure for All Files Access
    • Under All Files Access set Enable All Files policy to true to enable it.
    • In All Files apps list select Configure
    • Select the ellipsis (…) that’s next to All Files apps list and select Add Setting
    • Under Applications that require All Files permission in App package name enter in com.microsoft.scmx

These settings in Intune should be something like the below:

The settings look like the this, which is a little easier to read:

3.3 Defender Experience

What we have here are new profiles that should help our users on their way to onboarding their devices to Defender, without having to faff about setting up the additional requested permissions that Defender needs.

So when a user now opens the Defender app, they are only presented with one permission for Accessibility to configure:

I haven’t worked out a way to implement this using Intune or the Knox Service Plugin or Moto OEMConfig, so you’re end users will still have to do something to finish the onboarding process, sorry 🫠.

4 Defender Features

Now that you’ve got your Android Enterprise, and/or Samsung or Motorola devices onboarded to Defender for Endpoint, it’s worth covering off some additional settings and features to ensure that the app is not either misused, or to just be definite with some default settings.

So back to your App Configuration policy we go, to add in some or all of the below settings:

Obviously these can be amended based on your needs after reading through the associated documentation, and if you’ve got the bankroll to use Global Secure Access then can I borrow some money? 🤑.

5 Summary

Even with the additional configuration implemented for supported Samsung and now Motorola devices, it’s still not as seamless as the zero-touch onboarding available for iOS devices. Whether this is down to Android being fussy more particular with permissions and privacy settings than iOS or otherwise, users should not have to actively onboard their devices to a security service.

At least we’ve made the whole process a little easier for the Android users, and fixed some gaps with the Microsoft documentation.