After I published the article regarding the enrollment of Android devices in closed networks, the hottest question was how to apply it for China. The answer is as usual “it depends”. If you want to know more – read on!
- What’s the problem?
- What options are available?
- What is the optimal approach?
What’s the problem?
Problem is that Google services are banned in China. As such most of the popular international brands sell their devices there w/o GMS (Google Mobile Services), and even those with GMS cannot really use them. This results in the following limitations:
- No Play Store
- No Work Profile
- No Zero-Touch or KNOX Mobile Enrollment (!) either.
- No GMS initial setup wizard, which typically facilitates the Device Owner (Fully Managed mode) enrollment. This is important, since if the device vendor did not provide an alternative to enroll DO – you are stuck!
- No GMS libraries often used by the applications
So, what can we do?
First of all, since the Play Store is not available (neither public nor managed), all your apps must be deployed via MDM.
This is generally, not a problem. However, since Android 8 the OS native package installer performs a check for Internet based on accessing http://www.google.com, which may lead to failed installs. The workaround for Workspace ONE UEM is to use Product Provisioning, which uses our own installer. For other EMMs – talk to the developer.
Of course, if the apps rely on GMS APIs, and you have non-GMS devices – you are stuck. It is thus important to carefully select your apps, and if you must have apps that require GMS – consider how you will add those libraries onto the devices:
- Procure only the devices that have alternative GMS-enabled firmwares and reflash them.
- Leverage projects such as https://opengapps.org/ (I’ll leave the legality questions aside) to add GMS to existing devices.
In both cases you end up with a manual solution (which can be partially automated with a bit of scripting though). If you know a better way – feel free to suggest in comments.
Device Enrollment, Management, Security
The following options are available, with the following pros and cons.
1. Android Legacy (Device Administrator) management
It’s the same stuff that had been around for years. It works, for now. Problem is, ever since Android 8 it has less and less functionality / stability, and with Android 11+ it won’t work at all. Also, most EMMs are deprecating the Legacy DA management. It also provides limited security compared to Android Enterprise.
Overall I’d recommend it as a last resort option.
2. Android Enterprise Fully Managed (Device Owner) management.
As mentioned before, it is indeed possible when the following three prerequisites are met:
- MDM supports closed network enrollment. Not everyone does.
- Device vendor did not hardcode any GMS functionality in their initial setup wizard (precedents exist).
- Device vendor had implemented means to enroll DO.
The pros of this approach are quite obvious: it is standards-compliant, future-proof, you get full AE functionality and broadest security options possible. The cons are no privacy (device should not be used for personal purposes), the resulting need to carry 2+ devices, and [currently] very limited vendor support.
While Device Owner functionality is part of AOSP, the enrollment code is not (on GMS devices it is a part of Google’s own Initial Setup Wizard). AOSP assumes, since each device vendor would want to write their own setup wizard, based on the device specifics. Seems logical.
Alas, very few device vendors have actually bothered to create one, offering their customers a scalable method to enroll non-GMS devices. The list is maintained in this post. Everybody else requires a very laborious and manual process that involves ADB, described in the same post.
If you are a sizable enterprise buyer – apply pressure to your vendor. If you are a smaller player – consider buying devices that offer GMS firmware options and reflashing them into GMS.
3. Android Enterprise with VPN
I think the name says it all. If you enroll devices in a centralized fashion over a WLAN network hooked to a VPN you can get all the AE options: WP, DO, COPE. If you let users enroll devices (which means they have to get VPN app first), only Work Profile will be possible, since DO enrollment needs to be done before anything else is deployed to the device. Of course, device also must have a GMS firmware.
Pros and cons are quite obvious too: you get full spectrum of GMS services, Play Store etc., but they all may break any second.
4. Registered / MAM only Mode
Many EMMs offer an option to “register” device without actually enrolling it into MDM. In Workspace ONE this is called “Hub Registered Mode” for example, and I covered it here to some extent.
The biggest advantage of this method is that it will always work (provided your EMM supports it). The disadvantage is that you get 0.00% security and control over the device. You might address this by deploying a 3rd party EDR/MTD solution such as Lookout, Zimperium, Pradeo etc (provided they work in China) and leveraging their API level integration with your EMM to exchange the security and policy enforcement data (provided such integration exists).
Another alternative is using applications developed with MDM SDKs, such as Workspace ONE SDK or MS App Protection SDK (now part of InTune SDK), which can talk to WS1 UEM / Azure AD back ends, pull policies from there and otherwise protect themselves (featuring in-app encryption, in-app authentication, offline compromise detection and wipes etc). For instance, all WS1 productivity apps (Boxer, Content, Notebook etc) have WS1 SDK. Similarly, all (or nearly all) MS O365 mobile apps have those built in and can be managed via Workspace ONE (or other EMM that supports MS Graph API integration). Below are a few pictures from Workspace ONE UEM SDK default security options. These can be further customized per application via the SDK Profiles.
Overall, this may be a fairly good option if you are limited to BYOD or a small set of “enterprise-grade” apps than can protect themselves (WS1, O365 or your own in-house apps, where you can include the EMM SDKs). However, I would not deploy it without Conditional Access on the back end. I will talk about it later.
What is the optimal approach?
Overall, I would build my strategy for Android in China as follows:
- Wherever possible use AE Fully Managed devices (up to the point of buying ether GMS devices or devices for which GMS firmware exists and reflashing them if I can’t enroll DO otherwise) with closed network enrollment:
- Security, scalability, stability, full management options
- Since Play Store is not available, all applications deployed via EMM
- Users will have to have a separate phone for personal needs, but actually this is OK since I am NOT planning to allow any 3rd party app stores on my company’s devices anyway!
- Conditional access for device compliance checks
- If your deployment is small and you have a local tech, even a laborious ADB method may be OK.
- For devices that can’t enroll DO and for BYOD – use Registered Mode:
- All sensitive data (emails, company IP/files/etc) goes via MAM-enabled apps
- WS1 Boxer, WS1 Content for mail/contacts/documents/photos
- O365 apps with Graph integration where feasible
- SDK profiles deployed for strong on-device security (in-app auth, compromise detection, wipes etc)
- Restrict access to “company sensitive apps”
- Since all company apps are installed via the EMM, use smart groups based on the enrollment type to prevent the Registered devices from ever seeing the “sensitive” apps
- On the back end, use Conditional Access with compliance – registered mode devices will not pass compliance check
- If access to “sensitive apps” is nevertheless desired – deploy additional MTD/EDR security solution and integrate with EMM on the API level. Typically, if will result in generating some sort of compliance records, so the devices will be able to pass the conditional access checks
- Compliance policies that check for presence and status of the security tools and blacklist the device if those are not present are essential then (since we can’t deploy any corrective actions on non-MDM devices).
- All sensitive data (emails, company IP/files/etc) goes via MAM-enabled apps
- Last resort – Legacy (while it works) and/or VPN (while it works)
- Final, most important, note – try before you buy! You need to test everything end to end before committing!
My hope is that in the nearer future we will see more devices offering DO enrollment in non-GMS scenario, or more security options in the Registered mode, since Legacy and VPN cannot be relied upon.
What are your thoughts? Do you know better options? Care to share?