Discover account-driven User Enrollment

Hi, I'm Timm Hannon, an engineering manager in Core OS here at Apple. In this session, my colleague Melissa Nierle and I will cover User Enrollments for MDM.

User Enrollment is designed for BYOD, or Bring Your Own Device deployments where the user, not the organization, owns the device. Because the user owns the device, User Enrollment has a limited set of payloads and restrictions that can be applied to the device by the Mobile Device Management solution. And it's available on iOS, iPadOS, and macOS.

Security and privacy are at the heart of everything we do here at Apple. User Enrollment is a great device management option that incorporates both. Its design allows the user to be comfortable that their privacy and personal data are protected, while the organization can be confident their data is secure.

There are three core components that form the basis of User Enrollment.

The first is a Managed Apple ID. Managed Apple IDs provide access to Apple Services such as iCloud.

They are owned and managed by an organization and are available through Apple Business Manager and Apple School Manager. They support federation with Azure Active Directory so that users can authenticate with their organization's existing credentials.

The second is Data Separation.

During enrollment, a separate APFS volume with different cryptographic keys is created. Data from managed apps and managed accounts is kept securely on this volume away from personal content. When the device unenrolls from management, the volume and the cryptographic keys are erased.

And finally, the Management Capabilities are limited to those that are appropriate for controlling the organization's content on the device.

The user owns and has been using the device, so it's critical to protect their privacy.

With User Enrollments, the user maintains control of their personal data on the device. The device is not considered supervised with User Enrollment.

The management functionality available to the MDM server allows it full control of the managed content but is limited from accessing and restricting personal data and settings. Access to personal accounts, apps, and unique device identifiers is unavailable to the MDM server, as are system-wide operations like remotely wiping the device.

We've been hard at work this year on updates to User Enrollment, and I'm excited to discuss them now. I'll cover Managed Apple IDs and managed apps. Then my colleague Melissa will cover changes to the onboarding flows for users, how to enable ongoing User Authentication, and getting started.

Let's start with Managed Apple IDs.

In iOS 15, we've improved the experience of accessing the Managed Account in Settings. When a device is user enrolled, it will now show the account at the top level of settings. From there, you can view details and settings for iCloud. It is now easier than ever to manage the additional account. With this re-designed experience, Settings reflects the clear separation of organizational content. Users are able to see which parts of the system are managed by the organization and which are not.

New in iOS 15 and macOS Monterey, Managed Apple IDs support iCloud Drive. iCloud Drive is an important feature of iCloud accounts and now it will be available to user-enrolled devices.

On iOS and iPadOS, it shows up as a new location in the Files app.

And on macOS, it appears as an additional location in Finder. With iCloud Drive for Managed Apple IDs, organizations are now able to easily provide their users a built-in cloud storage solution.

Document browser-based apps will also have access to the additional iCloud Drive. And of course, iCloud Drive will respect Managed Open-in restrictions for managed apps and data access.

Now let's turn to managed apps.

In macOS Big Sur, we enabled managed apps on macOS for the first time.

This allows organizations to install apps on a managed device similar to how they can for iOS, including with a custom configuration payload.

It also provides the ability to remove the app with an MDM command or when the device unenrolls.

In macOS Monterey, we are expanding the functionality to user enrollments.

Like on iOS, the app data is separated on a different volume. The app is removed during unenrollment or with an MDM command. When that happens, the data container is also erased.

Managed apps that use CloudKit will now use the Managed Apple ID associated with the MDM profile. You'll need to add the InstallAsManaged key to the InstallApplication command. And just a quick reminder that managed apps need be installed to the Applications folder and should only contain a single app bundle. We recommend that you adopt the use of the Data Protection Keychain and app sandboxing to ensure that data is correctly separated.

We've also added some enhancements to managed apps for all types of enrollment that are relevant to user enrollments. First, the restriction functionality for Managed Open-In has been expanded to include Copy & Paste. This will allow organizations to control data from being pasted across the managed boundary in both directions.

There is also now the ability to specify that a required app is installed when a device enrolls in management. The app is approved for installation when the device is enrolled, so it doesn't require additional user confirmation. For more information on managed pasteboard and the required app installation, see "What's new in managing Apple devices." Now over to Melissa to cover enrollment and ongoing user authentication.

Thanks, Timm. With all of these enhancements to User Enrollment, we updated the onboarding flow to be a more personalized and user-driven experience. The onboarding experience for User Enrollment introduced in iOS 13 is initiated and driven by an MDM Enrollment profile. This profile has to be created for each user and distributed by their admin.

In iOS 15, for a more streamlined experience for both users and administrators, we've created a new User Enrollment onboarding flow that establishes the user's organization identity as the entry point.

Users are already familiar with signing into their organization identity to set up services like Mail and Calendar, so they'll be familiar with setting up MDM on iPhone using their organization identity. This onboarding flow enables new security features for User Enrollment. Now there's a layer of security during the enrollment flow where your MDM server can verify the user before the MDM profile is even downloaded to the device and before any organization data is sent to it.

Let's take a look at how this new account-based flow works.

There are four components to the new User Enrollment onboarding flow. Service discovery, where the device identifies the organization's MDM server.

User authentication, which is how the MDM server validates the user.

Issuing the session token, which is how ongoing authentication is performed.

And enrollment, which is the installation of the MDM payload to the device. Let's take a closer look at each of these.

When the user starts the onboarding flow, they are prompted to enter their organization identifier.

This identifier has two main pieces, delineated by the @ sign. The first piece will be the User ID, and the second piece will be the organization's domain or a sub-domain. After the user has entered their organization ID, the device takes the domain portion of the identifier and turns that into an HTTPS URL pointing to a well-known HTTP resource at that domain.

This discovery URL is where you host your MDM server document that tells the device where the enrollment endpoint is.

The device then performs a GET request to that URL, expecting to get back a JSON document.

The received JSON object includes a version key to let the device know what type of enrollment the server supports and a BaseURL key that specifies the URL of the MDM server's enrollment endpoint.

With this information, the device is now ready to request the enrollment profile from the server.

The device POSTs a property list to the server's enrollment endpoint with various device attributes.

If you are familiar with the over-the-air profile delivery process, you will recognize this as the same request a device makes to the profile service endpoint.

But the key difference here is that the server asks the user to authenticate themselves before it hands over the enrollment profile.

It does this by issuing an HTTP 401 Unauthorized response to challenge the user for credentials. The server must issue this auth challenge in order for enrollment to succeed.

Importantly, this 401 response includes a WWW-Authenticate header with information that the device uses to authenticate. This WWW-Authenticate header uses the Bearer authentication scheme and two additional parameters.

The method parameter tells the device what type of authentication is being used. The value indicates that the device will use the AuthenticationServices web sign-in flow to authenticate the user. For now, that value is fixed.

For this method parameter, a URL is also included.

The value of this key is an HTTPS URL that specifies the endpoint where the authentication happens. This URL should be an endpoint on the MDM server itself. Receipt of this authenticate header kicks off the AuthenticationServices web sign-in flow. Let's take a look at how that works.

The initial content of the web view displayed by AuthenticationServices web sign-in flow is the result of a HTTP GET request to the authentication endpoint specified by the URL parameter from the 401 response.

In a simple case, this web sign-in flow could display a web form where the user would enter their username and password.

In more complex cases, it could make use of enterprise single sign-on or even redirect to a third-party identity provider or perform multi-factor authentication.

Multiple round trips between the device and authentication service can occur. The AuthenticationServices web flow completes when the server returns an HTTP redirect response to the device, like the one seen here.

The response includes a Location header with a URL using a custom fixed scheme.

The URL also includes an access-token parameter whose value is an opaque token that the device will use as a session token when making requests to the MDM server.

With the session token in-hand, the device re-issues the original HTTP POST request to fetch the enrollment profile.

This time, that request includes an Authorization header which contains the session token as the value. The server validates this token, and upon success, returns the enrollment profile to the device. The user enrollment profile contains two new keys in the MDM payload.

First, the AssignedManagedAppleID key is the Managed Apple ID associated with the enterprise user. The user will be required to authenticate this Managed Apple ID to sign into the iCloud and iTunes accounts as part of the enrollment flow.

A successful MDM enrollment guarantees that the Managed Apple ID is active on the device. The device will fail to enroll if the AssignedManagedAppleID key is missing or if the user does not successfully authenticate it.

And the second new key is the EnrollmentMode key, indicating the enrollment is a BYOD type. The device verifies that this value matches the mode it is in and will fail the enrollment if there is a mismatch or if the key is not present. Be sure to update your MDM payloads with both of these new keys. With receipt of the enrollment profile, the device now sets up the required Managed Apple ID account and enrolls with the MDM server. All requests to the server now include the session token in the Authorization header for the server to validate. Let's take a look at all of the pieces together. First, the user navigates to the redesigned VPN and Device Management section in Settings and taps the new Sign In to Work or School button. Then they enter their organization ID, triggering the service discovery step. After discovering the enrollment endpoint from the domain, the Authentication Services Web UI flow begins. This is an example of a simple web form used for auth. The user enters their organization password. Once the organization's authentication succeeds, we are handed the MDM profile. We take the value of the AssignedManagedAppleID key from the profile and pre-populate it into the next sign-in screen, where the user enters their password. After this authentication succeeds, the user then allows management of their device.

They enter their device passcode to create an encrypted enterprise data partition and to authorize the MDM enrollment. The enrollment of the user is successful. And that's the new account-driven onboarding flow for User Enrollment. In the onboarding flow, we looked at how a server authenticates a user before sending enrollment data. With new User Enrollments in iOS 15, we are introducing the ability for organizations to reauthenticate the user at any point in time. This makes it possible for your server and client connection to be more secure than ever. MDM servers can now validate authorization on every request from the client and ask the user to re-authenticate their identity credentials at any time. This functionality is performed through the use of the session token.

Here's an example of an MDM client checking in with the server to fetch the next MDM command. The Authorization header contains the session token. This is the staple for the two elements of ongoing authentication.

The first element is persistent authorization, where the session token is sent in every client request to the server.

The second element is refreshing the session token. This enables the organization administrator to request user re-authentication at any time.

By implementing your own server side validation logic of this session token, you can add your organization's security rules right into your management solution.

For example, you can periodically verify a user's credentials to ensure sensitive payloads are only sent to devices in possession of trusted users.

Let's take a look at how that works.

When the session token is invalidated, re-authentication is triggered.

The next time the device makes an MDM HTTP request, the now invalid session token included in the HTTP PUT will trigger a 401 response from the server.

The response that the server sends includes the same WWW-Authenticate header that we saw earlier in the initial authentication exchange during the onboarding flow.

Of course, because the MDM process runs in the background on devices, this reauthentication request is surfaced to the user via NotificationCenter.

By tapping on the notification, the user continues the re-authentication flow in Settings.

The client will start another AuthenticationServices Web sign-in flow like the one during the onboarding process.

The user will need to authenticate as part of the AuthenticationServices web sign-in flow with either a simple mechanism or a more complex one decided by the server's integration with their identity provider.

When that authentication services web flow completes, the server again sends a redirect response with the custom Location header, containing a new session token.

A successful re-authentication results in the device immediately repeating the MDM request that initially received the 401 response, continuing right from where it left off without action from the server. Just like before, this new session token is included in all subsequent MDM HTTP requests. If, for any reason, a user's authentication attempt fails, the server may no longer trust the device.

In this case, the server can remove any sensitive MDM payloads or it can completely unenroll the device.

And when it comes to unenrolling from MDM, because ongoing authentication leverages the HTTP 401 response, it's important to note a key difference here between profile-based enrollments and this new User Enrollment.

Before iOS 15, all MDM-enrolled devices treated a 401 response from the server as an unenroll command. When this new User Enrollment style is in effect, the 401 response triggers reauthentication instead.

To trigger an unenroll, you can still use the existing mechanism of sending the RemoveProfile command for the MDM enrollment profile. This will result in a full MDM unenroll as well as a complete managed account, managed data, and data separated volume removal from the device.

All unenroll behavior of profile-based enrollments, including the user enrollment flow from iOS13, remain unchanged.

So that's a quick look into Ongoing Authentication. Now let's help you get started and wrap up. You can get started with the new User Enrollment onboarding and ongoing authentication today with iOS 15. You'll need be sure to do these five things. First, set up and publish an HTTP well-known resource file for your enterprise domain.

Second, integrate your MDM server with your Identity Provider to perform user authentication during enrollment and take advantage of the ongoing authentication for added Security benefit.

Third, create Managed Apple IDs or use already created Managed Apple IDs from Apple School Manager and Apple Business Manager to populate the AssignedManagedAppleID key in your server's MDM payloads.

Update your MDM payload to also include the new EnrollmentMode key.

And lastly, find our new iOS 15 Apple Device Management documentation to review our specific updates along with all the details that we've gone over today. And that's all you need to get started with Account-Based User Enrollments. We covered a lot today, so let's review. The new iCloud Drive support for Managed Apple IDs brings a built-in cloud storage option to your organization. You can now manage apps on macOS in User Enrollment. Build support for the new onboarding flow in your MDM solution or encourage your MDM provider to support the new account-driven onboarding to make user enrollment easier than ever before.

Incorporate ongoing authentication with your accounts throughout your management workflows.

Take advantage of these new features starting in iOS 15 and macOS Monterey to significantly improve the Bring Your Own Device workflow for both you and your users. Thanks for joining us today, and have a great WWDC. [music]