Apple iOS User Enrollment vs Android Enterprise and the real MDM needs #WWDC2019

Every WWDC has a session called What’s New in Managing Apple Devices. This year’s one was no exception. During this session Apple presented they new take on BYOD called User Enrollment. Here’s my brief analysis and comparison with Android Enterprise. Links to the source video, slide deck and some other useful resources are below.
TL:DR : Good stuff, but fell short.

iOS 13 User Enrollment. This and other pictures form the original slide deck linked below.

Why?

In the last few years the gap between Android Enterprise and Apple’s MDM implementation widened. Where AE (not without it’s own issues) clearly defined a number of use cases, such as Work Profile, COSU, COPE etc, Apple basically had two methods: Device Enrollment (DE) and Supervised (DEP / Apple Configurator). The Supervised can be related to Work Managed, while Device Enrollment was akin to legacy Device Administrator on Android. On one side it did not provide full management capabilities (you need Supervised for that) or full user/work data separation (an app can only work either with personal or work data, but not both). On another side – there was no way for the user to prevent Admin from viewing their personal apps, taking management over those apps, wiping the device fully etc.

Thus, neither management nor privacy objectives were fully achieved. With the addition of User Enrollment (UE) the delineation between fully managed (Supervised) and BYOD (User Enrolled) devices is clearer. Given that since iOS11 we see many management and security options migrating from DE to Supervised, I won’t be surprised to hear that DE will be end of life in iOS 14 or 15.

The three new options for iOS MDM: BYOD, Legacy and Fully Managed

What does it do and how does it compare?

Let’s now take a look at the key principles of UE, the gaps is closes, the gaps it still leaves, and how does it compare to the Work Profile in Android Enterprise.

The three pillars of UE are:

  • Leveraging Managed Apple IDs
  • Full Data Separation
  • Reduced management in favour of privacy

Managed Apple IDs

Using Managed Apple IDs is quite similar to Managed Google Play accounts of Android Enterprise. With the exception that the Managed GPlay accounts are created automatically, while the Managed Apple IDs must be created manually in ABM. But since ABM now allows for federation, which means that for most people their managed Apple ID will be the same as their corporate ID, it actually makes sense!

On the other side, since all the work apps will now be ONLY able to see that ID (and the user’s personal ID is never exposed to MDM) we get the necessary degree of privacy.

Still no Dual Persona

At this point in the presentation I got really excited until the below showed up:

Still no dual persona apps except a few of Apple’s own. Maybe later?

Just a few Apple’s own apps can support both personal and managed Apple IDs, but the 3rd party apps are still limited to the “either / or ” scenario – we’re still not getting the “Dual Persona” approach that Android Enterprise Work Profile provides. This is a serious gap, especially given that now MDM Admin cannot force the app to become MDM managed. Right now it’s unclear what happens when the MDM tries to push an app that is already installed by the user, but most likely it will just fail.

Requiring user to sacrifice one of his apps and choose between productivity and comfort sucks, but I have a feeling that this has more to do with patents and politics, rather than with Apple unable to “innovate on” the Android’s approach 🙂

Data Separation

Similar to the previous Managed Data and AE’s Work Profile, all the work data un UE mode is stored on a completely separated partition. This includes

  • App containers
  • Notes
  • iCloud Drive documents
  • Keychain
  • Mail attachments and full email bodies
  • Calendar attachments

Unenrolling destroys the whole partition. This is very similar to the “All or nothing” approach in the Work Profile (have it or wipe it at any time) and allows for future extensibility such as “quiet times” or “off work” mode (just purge the key temporarily). This also makes management and security within the OS itself simpler (partition access is easier to control than a bunch of folders = less bugs and exploits). Overall, a welcome upgrade.

Management Restrictions for Privacy

Apple is famous for their “Privacy First” approach, and hopefully, having a clearer delineation will also mean that the Supervised devices will suffer less encumbrances and more MDM automation in the future (CallerID, Location etc).

UE is built to assure privacy, thus restricting many management features.

  • Profile Services Profiles won’t work. Looks like Apple is developing a parallel set of Configuration Profiles for UE mode, as all current MDM Profiles are Profile Services-based. I did not quite get this, and the presenter did not device much time to it. Anyway, here you can click through all possible payloads and see which of them work with UE. If you have a better explanation – please leave a comment!
  • No device IDs. In UE mode the MDM system will not see UDID, EAS ID (Exchange ActiveSync), Serial, IMEI MAC or anything else. Combined with the MAC Randomization also in effect on iOS since quite a while, this is going to bring the same effects as on Android, but worse. But then, these are BYOD devices, so it should not matter much …except the next point.
  • Device ID and EAS ID change on re-enrollment. This can have interesting effects on the license counts in MDMs, if the user wipes and re-enrolls their device several times. How does your MDM count licenses? Can you clean up automatically and how can you tell a duplicate from a really inactive device?
  • Limited visibility, lock and wipe. MDM now cannot see privately installed apps, certificates and profiles, cannot reset device passcode, cannot wipe the device or unlock it. Similarly EAS can only wipe the account, and not the device. All this makes total sense, but yet again there’s a “but”…
  • Passcode enforcement is limited to 6-digit complex PIN. Yes, you’ve read it right. Apple’s response is that making it any harder (longer, with letters etc) “increases the chances or user forgetting the passcode”, and since the MDM now can’t reset it, there is a danger of user locking themselves out. Now, go tell that to your InfoSec team! 🙂
    In a typical Apple “you’re holding it wrong” fashion they are even going to release a document, to explain why 6-digit PINs are good!
    On the positive side, in most cases those BYOD devices won’t have access to any sensitive data/apps anyway, so it’s not that bad as it looks on the first side.
    Nevertheless, compare with Android’s Work Profile, where one can have separate passcode policies for the device and WP itself. Simply elegant!
  • Apps are always removed on unenroll. This also makes sense, as well as not being able to force an app into an MDM managed state or “unmanage” an app. Nice and clean.
  • VPP with managed Apple IDs now makes sense. Device-based assignment still works, but now if the user uses the same managed Apple ID across multiple devices (BYOD and Corp) – you don’t need multiple licenses. Makes sense!
  • Per-App VPN domain match. Per-App VPN server 2nd level domain must match the email. I.e. vpn.corp.com will only work if users email is email@corp.com, but not emai@othercorp.com. This one may or may not be a challenge for large organizations with lots of DNS legacy, but generally should not be a challenge. Compare to Work Profile, where such limitation is not needed due to clearer separation.
  • Not supported: Wi-Fi Proxy (use WPAD), Default and Logging (must be explicitly installed by user), lots of restrictions that are supervised-only or make no sense to BYOD.

Smoother enrollment

The UE enrollment flow is a little smoother than old DE with a few shortcuts and combined steps, but nothing outstanding. You can see the demo in this video beginning at 20:45.

MacOS too

MacOS will also support User Enrollment. There wasn’t much said, so I’ll leave you with the slide.

Summary and analysis

Overall, this is definitely a step in the right direction:

  • Better privacy and good data separation
  • Better delineation between BYOD and Company-owned devices
  • Managed IDs make sense and allow new use cases for VPP
  • Simultaneous launch for iOS and macOS
  • Ability to completely obsolete the legacy Device Enrollment down the road

But I feel disappointed at how this was implemented compared to Android Enterprise Implementation. It fell way short of expectations

  • Password limitation is silly, and the “you’re holding it wrong” approach is arrogant
  • Dual persona is not there, apps can’t use multiple accounts
  • No managed app store
  • Many other limitation that don’t appear by design in the WP architecture (VPN, device IDs etc)
  • Nothing about device health attestation for Zero-Trust / Conditional Access, which is especially important given the limitation on management and policy enforcement!

And we had not compared it with COPE yet, or the upcoming “Work Profiles for company-owned devices” in Android Q! Interestingly that they are being released the same year – could it be that after all those years we’re seeing the year of BYOD?

What both Android and Apple are missing (and it’s getting hotter with time) is the ability to support multiple work profiles. The contactor/freelancer model is getting more and more popular, and I keep hearing more requests for providing those people access to apps and networks, as well as enforcing better security. I think both Google’s and Apple’s current BYOD models can support this use case with ease. Could it be the next year’s theme? What do you think?

Further Resources:

Advertisements

2 thoughts on “Apple iOS User Enrollment vs Android Enterprise and the real MDM needs #WWDC2019

  1. To clarify, in your blog post you wrote, “all current MDM Profiles are Profile Services-based”, but that’s not the case. A profile service profile is a different kind of profile where instead of installing a profile’s payloads directly, the device requests the final payload from a server. Because the profile service mechanism involves providing persistent device identifiers to the MDM server, it cannot be used with user enrollments.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s