Last week, I wrote about a new world in iOS MDM called Declarative Device Management. One truth is very clear: Desired State Management is the goal of every organization, but can you actually move to iOS User Enrollment without compromising your mobile strategy? We’re going to discuss a few things: (1) What is iOS User Enrollment?, (2) the gaps when moving to iOS User Enrollment, (3) can we fill any of those gaps, and (4) a demo of the iOS user enrollment experience. Let’s get started!

What is iOS User Enrollment?

Apple introduced iOS User Enrollment in iOS 13, which is their foray into an Android Enterprise-like model of BYOD. Rob Terakedis wrote a really good primer on iOS User Enrollment so I won’t go too crazy, but let me give you a few of the key highlights.

• Leverages Managed Apple IDs powered by Microsoft Azure, which your organization owns.
• Creates a container/separate volume on the device to truly deliver work separation.
• No agent lives on the device.
• Web-based enrollment.
• Leverages your SSO for Azure to log you in and enroll your device.
• Managed areas include apps, notes, calendar attachments, keychain items, mail attachments, and mail body to name a few.
• Limited visibility and only the apps you push are delivered aka no app catalog

Now that you have a basic idea of how user enrollment works, lets check out a demo of the user experience on enrollment.

As you saw in the demo, the iOS User Enrollment is pretty simple. We basically install a profile and it will perform a clean and simple BYOD enrollment. I actually got a little crazy and decided to breakdown how VMware does it. Let’s review how that part of the enrollment works.

When you browse to your URL in VMware Workspace ONE e.g. https://ds1688.awmdm.com/enroll/user it will download a profile, which is installed and bridges you to the iOS User Enrollment. The code itself can be found here. I think its fine to show off the code as the profile is just for testing but its interesting to show it off. At some point, I’m going to see if there’s a way to build our own and deploy to simplify user enrollment.

<dict>
    <key>PayloadContent</key>
    <array>
      <dict>
        <key>Topic</key>
        <string>com.apple.mgmt.External.478f9bde-850c-47d2-9ad0-78f9fb82fe88</string>
        <key>UseDevelopmentAPNS</key>
        <false />
        <key>IdentityCertificateUUID</key>
        <string>8d6a2061-cf46-414c-8917-8c5e1d26f769</string>
        <key>SignMessage</key>
        <true />
        <key>AccessRights</key>
        <integer>8179</integer>
        <key>CheckInURL</key>
        <string>https://ds1688.awmdm.com/DeviceServices/AppleMDM/CheckIn.aspx?deviceId=27968c0b-7d07-4191-bccf-f93855fb9016</string>
        <key>ServerURL</key>
        <string>https://ds1688.awmdm.com/DeviceServices/AppleMDM/Processor.aspx?deviceId=27968c0b-7d07-4191-bccf-f93855fb9016</string>
        <key>CheckOutWhenRemoved</key>
        <true />
        <key>ServerCapabilities</key>
        <array>
          <string>com.apple.mdm.per-user-connections</string>
        </array>
        <key>ManagedAppleID</key>
        <string>[email protected]</string>
        <key>MutualTlsAuthenticationCertificateUUID</key>
        <string></string>
        <key>PayloadDisplayName</key>
        <string>MDM Settings</string>
        <key>PayloadDescription</key>
        <string>MDMSettings</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadType</key>
        <string>com.apple.mdm</string>
        <key>PayloadUUID</key>
        <string>97763921-f7cb-4406-8a38-70f31779f751</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadIdentifier</key>
        <string>b7f78acf-bc0a-4100-9d73-7c41e45c5e7e.MDM Settings</string>
      </dict>
      <dict>
        <key>PayloadDisplayName</key>
        <string>Airwatch MDM</string>
        <key>PayloadUUID</key>
        <string>8d6a2061-cf46-414c-8917-8c5e1d26f769</string>
        <key>KeyUsage</key>
        <string>Authentication</string>
        <key>ManagedAppleID</key>
        <string>[email protected]</string>
        <key>PayloadType</key>
        <string>com.apple.security.pkcs12</string>
        <key>Password</key>
        <string>cba338c10e254f63bed5c8026c46fa29</string>
        <key>PayloadDescription</key>
        <string>CredentialSettings</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadIdentifier</key>
        <string>b7f78acf-bc0a-4100-9d73-7c41e45c5e7e.Certificate</string>
      </dict>
    </array>
    <key>PayloadDescription</key>
    <string>Workspace profile to separate work and personal data and activate access to work applications and services on your device.</string>
    <key>PayloadDisplayName</key>
    <string>Workspace Services</string>
    <key>PayloadIdentifier</key>
    <string>b7f78acf-bc0a-4100-9d73-7c41e45c5e7e</string>
    <key>PayloadOrganization</key>
    <string></string>
    <key>PayloadRemovalDisallowed</key>
    <false />
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>fbc7a831-4b86-4f6f-aabd-1a0df6bc852f</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
  </dict>

The Gaps when Moving to iOS User Enrollment

Obviously, I realized we have to move to iOS User Enrollment to capitalize on the crucial capabilities of iOS 15. The first step is to look at what the actual gaps are. Below, you will find a spreadsheet that I built which gives you a deep view into what you can and cannot do.

Now, let’s cover the management gaps and application management gaps that exist in iOS User Enrollment.

Gaps in Management for iOS User Enrollment

iOS User Enrollments being a BYOD concept offer a small subset of capabilities. Let’s cover what you can actually do. As you can see in the spreadsheet, you can use the following profiles:

• Google Accounts, Contact Accounts, and Calendar Accounts
• LDAP Accounts
• AirPlay and AirPrint
• SSO
• Certificates
• Email
• WiFi
• Restrictions (A Subset, which we will discuss shortly)
• 6-digit Passcode
• Fonts
• App-Layer VPN
• Webclips

You can see there’s significantly fewer settings than with a traditional MDM enrollment. With restrictions, we have limited options also:

Managed Pasteboard

Apple Diagostics Submissions

Screenshots and Screen Recording

Siri

Controlling Siri When Locked

Enterprise Book Backups

Enterprise Book Metadata Sync

Control Center Lock Screen

Notifications View Lock Screen

Today View Lock Screen

Managed Apps Cloud Sync

Secure Open-In

Allow Unmanaged Apps to Read Managed App Contacts

Control Unmanaged AirDrop

AirPlay Pairing

Encrypted Backups

Enforce Apple Watch Wrist Detection

Safari Fraud Warnings

Problems with Application Management

iOS User Enrollment is very unclear with the gaps on applications. Let’s cover those.

Firstly, your managed apps are found directly in the MDM profile as you can see below or you can push out the Intelligent Hub application to users:

There has been a ton of confusion on what is actually allowed and what you can do around apps. After some testing, here are the basic guidelines:

• You will need to figure out a way to differentiate your devices that are user enrollment and those that aren’t to account for different requirements.
• “Assume Management” is not supported and you will not be able to push apps that require that. You will see something like in your troubleshoot logs:

By accessing the Apple MDM documentation, that error code translates to “malformed request.”

The general rule via Apple on applications with iOS User Enrollment is that if an application already exists on the device it cannot be pushed. A piece of misinformation is that App Config keys are not supported, but I can tell you that they are 100%. It’s too bad that you cannot access an App Catalog, but I will be doing some additional testing to come up with a workaround on that.

Update: I’ve identified that you can use the Intelligent Hub as a solution for your self-service needs, which is a huge help.

Some Thoughts on the Gaps

Obviously, there’s some major concerns around the gaps that exist today. The good news is there aren’t a ton of profiles that aren’t supported. Some of them include:

• Web Content Filters
• Managed Web Domains
• Some of the VPN options

There are many more unsupported restrictions:

iCloud Address Book, Bookmarks, Calendar, Docs, iCloud Mail, Notes, Reminders, Photo Library, Photo Stream, Shared Stream

Content Catching

iTunes File Sharing

Force AirPlay Pairing Password

Activity Continuation

Auto Unlock

Touch ID

Spotlight Internet Results

Apple Personalized Advertising

Bookstore Erotica

Enterprise App Trust

Allow Background Fetch while Roaming

In-App Purchases

Allow Managed to Write Unmanaged Contacts

OTA PKI Updates

Passbook While Locked

Shared Device Temporary Session

Untrusted TLS Prompts

Voice Dialing

Software Update Deferment

iTunes Store Password

Limit Ad Tracking

Limit or Force Dictation to be On-Device

Movie, TV Show, Region, and App Ratings

Safari Cookies, JavaScript, and Popups

After reviewing the above, you can see that there are some definitely concerns.

“Inevitably iOS User Enrollment comes down to if their gaps are also your gaps.”

The areas that jump out to me the most are (1) managed web domains, (2) content filters, and (3) OS version deferment. Next, we are gong to be discussing some potential ways to mitigate some of these issues.

Trying to Fill the Gaps of iOS User Enrollment

We are going to focus on mitigating three of these issues: (1) content filtering, (2) VPN access, and (3) managed web domains. Our friend Microsoft is going to be our best friend to try to fix some of these problems.

Using Microsoft Defender to Work with Content Filtering

Microsoft Defender is a bit trickier. I covered how to setup Defender on iOS in a very clean way, but look what happens when we try it with iOS User Enrollment:

That means, you will have to decide if content filtering is important to you. Basically, you can still push the app, but users will need to accept some prompts to allow it on their device. Let’s check the demo!

Of course, you can use any other product you want for content filtering, but this is an option for many of us. Now, let’s move onto the much more complicated web domains.

VMware Tunnel: The VPN Salvation

Here’s the good news. VMware Tunnel happens to be an App-Level VPN solution. You are going to find many VPN solutions won’t work with iOS User Enrollment. I tested out and validated the payloads and we are safe there for those who use the VMware Tunnel. I would expect that the Microsoft Tunnel will be in a similar situation, but I haven’t tested it yet.

Update: It appears a bug has surfaced around Per-App VPN and iOS User Enrollment. Below, you will see Apple’s response on the bug around the certificate being unable to be fetched with this error:

Failed to load client certificate identity from keychain
 Gateway (D) TLS certificate does not match any available pinned certificates

Apple Engineering is aware of an issue involving MDM User enrollment and Per-App VPN. It is being actively worked for resolution in a future release of iOS. There is no ETA for resolution on this issue, so it’s recommended to use another workflow to achieve the desired result for the time being. 

Leveraging App Protection Policies to Solve Managed Web Domains

This is a situation that is very complicated. Let’s start by explaining managed web domains. Apple’s strategy on DLP focuses on only letting apps that your company manages access your data. As an example, you should be required to use managed apps for accessing attachments in your company email. So how do you solve this problem when using Safari?

Apple introduced managed web domains to tell your device what web addresses are considered company-managed vs. personal. Now, enter iOS User Enrollment, which does not allow for managed web domains. So, how can we possibly move to iOS User Enrollment with such a gap in your security? Any ideas Microsoft?

Moving to Microsoft Edge as your Managed Browser

We now have a solution thanks to Microsoft’s App Protection Policies. Our solution is two parts, which we will now discuss.

First, you update your Mobile SSO profile to no longer allow Safari and add in Edge.

That part is relatively straight-forward. The idea being that if your app isn’t listed in there then you can’t use it for SSO, which solves most of the problem considering you need to be able to log into a company app to be able to exfiltrate data.

Next, you configure an App Protection Policy for Edge. The app protection policy ensures only other Intune-protected apps can transfer data with Edge or apps you implicitly whitelist within the application itself. You will see essentially that you create a policy where you lockdown “Send org data to other apps” and leverage the exempt apps capabilities to allow exactly the apps you need. You want to remember that if the app needs to use Edge for SSO that it will need to be exempted most likely as most apps try to use browsers to login. Additionally, your app will need to support using Edge as a browser.

Final Thoughts

So, there was a ton to digest here. Like I said last week, iOS 15 has now made iOS User Enrollment a user experience imperative. An architect doesn’t sit here and find reasons not to do something. They figure out how we can make it happen. Plugging the gaps are rough, but most people will be able to. The longer we wait, the harder it will be to get there. I’ll meet you on the other side!