I work with many organizations who are beginning to migrate from Android device admin enrollments to device owner (i.e. Android Enterprise). While migration to device owner requires a factory reset on the device, once enrolled with device owner, devices have a more standardized approach to management and consistency vs. the fragmented management experience device admin enrollments exhibit when multiple OEMs are being managed.
Realizing there was a need to standardize and secure devices beyond the device admin APIs, years back Samsung introduced Knox. Samsung Knox provides an additional set of security and management APIs built on top of Android and is included with many Samsung devices. EMMs, including Microsoft Intune, also took steps to integrate with Samsung Knox to provide a rich set of management capabilities where the device admin APIs didn’t cover (e.g. email profiles).
Google requires device OEMs wanting their devices to be Android Enterprise Recommended (AER) to meet certain requirements thus standardizing and provide consistency across the Android Enterprise device ecosystem. However, Samsung Knox remains available and continues to provide security and management features, in some cases, beyond what Android Enterprise offers with their current set of APIs. Although Android continues to update/add security and management features with every API version.
With Android device owner enrollments, Samsung and other OEMs support OEMConfig. OEMConfig provides a set of OEM specific features EMMs can configure along with standard device settings.
What is OEMConfig?
“OEMConfig policies are a special type of device configuration policy very similar to app configuration policy. OEMConfig is a standard defined by the AppConfig community (opens another web site) that allows OEMs (original equipment manufacturers) and EMMs (enterprise mobility management) to build and support OEM-specific features in a standardized way. Historically, EMMs, such as Intune, manually build support for OEM-specific features after they’re introduced by the OEM. This approach leads to duplicated efforts and slow adoption.
With OEMConfig, an OEM creates a schema that defines OEM-specific management features. The OEM embeds the schema into an app, and then puts this app on Google Play. The EMM reads the schema from the app, and exposes the schema in the EMM administrator console. The console allows Intune administrators to configure the settings in the schema.
When the OEMConfig app is installed on a device, it can use the settings configured in the EMM administrator console to manage the device. Settings on the device are executed by the OEMConfig app, instead of an MDM agent built by the EMM.
When the OEM adds and improves management features, the OEM also updates the app in Google Play. As an administrator, you get these new features and updates (including fixes) without waiting for EMMs to include these updates.”
Source: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview
Although Samsung offers OEMConfig settings, some Samsung features/settings require a Samsung license, for more details please visit: https://www.samsungknox.com/en/blog/knox-platform-and-android-enterprise
Intune documention on OEMConfig may be found here: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview
Let’s get started with OEMConfig with Intune and a Samsung device
Samsung Knox Service Plugin
First, let’s add the Knox Service Plugin from the Managed Google Play store which is required to deploy OEMConfig policies to Samsung devices.
Assumptions: Intune is already connected to Managed Google Play, if it’s not you can find details on how to do this by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise
We’ll do this by navigating to https://devicemanagement.microsoft.com -> Client apps -> Apps -> Add -> App type = “Managed Google Play” -> select Managed Google Play Approve
To learn more about Samsung OEMConfig settings, browse through the Knox Service Plugin (KSP) admin guide: https://docs.samsungknox.com/knox-service-plugin/admin-guide/welcome.htm
Creating an OEMConfig profile for Samsung in Intune
Navigate to Device configuration -> Profiles -> Create profile -> add a name -> Platform = Android Enterprise -> Profile type = OEMConfig
Associated app = Knox Service Plugin – this is the app added in the previous step.
Select OK after selecting Knox Service Plugin.
After selecting OK we’re taken to Settings where we’ll see a full page of JSON. Don’t be intimidated it’s straight forward once you understand the structure which are just key/value pairs.
Update: as of the Intune 1907 release there is now a configuration designer with a UI, so no need to edit JSON.
Continue reading for additional details about these settings and details about JSON if you prefer to edit manually:
Either select all and copy or select Download JSON template and open in your favorite text editor.
There are a couple values I want to point out in the JSON:
I mentioned at the beginning some Knox features/settings may require an additional Samsung license, this is where the license key would be set:
We want to turn on the policies, do this by setting doPoliciesIsControlled to “true”
Troubleshooting – everyone likes an easy method to troubleshoot a device and by setting verboseMode to “true” will enable you to view the policies deployed to the device via the Knox Service Plugin app. More on this later in the post.
There many settings that are controlled with OEMConfig, however for the purposes of this post I’m going to turn off face recognition and only allow fingerprint. Disable face recognition by setting doPasswordBioFace to “false“.
Note: blocking the ability to use Face unlock to unlock the phone doesn’t prevent the device user from adding their face recognition. They just won’t be able to log in with face recognition as password and fingerprint are allowed in the OEMConfig.
Once you’ve completed filling out the JSON, copy and paste into Intune where you originally copied the JSON from and select OK then Save.
Note: you don’t have to have every key/value in the profile present, feel free to delete key/values from the JSON, just make sure the formatting is correct.
Device view
Once the policy is targeted to device it should only be a few seconds or so before the policy gets pushed to the device through Google services.
We can check if the policy deployed by opening the Knox Service Plugin app and selecting “Configuration on yyyy/mm/dd” (e.g. “Configuration on 2019/07/08”)
Select the “Configuration results” dropdown and select “Policies received” and from here we see the same JSON that was deployed from Intune.
Look for the password policy in the JSON as shown below:
On the same Samsung device navigate to Settings -> Biometrics and security -> Face recognition -> enter your password if prompted and we see “Face unlock” is disabled. Again, we can add face recognition, however we can’t use it to unlock the device, so it’s essentially benign.
Here’s a video of the process above:
Mobility, Management, & Security 