Explore advances in declarative device management

♪ ♪ Cyrus: Hello and welcome to the "Explore advances in declarative device management" session. My name is Cyrus Daboo, and I am an engineer on the device management client team. I am here to describe to you the exciting new features of declarative device management. Declarative device management is the new device management solution for all your Apple devices. It provides an autonomous and proactive management capability that allows devices to apply management logic without prompting from the server, and supports asynchronous status reporting, avoiding the need for servers to poll devices.

Also, it is built into MDM to allow an easy transition and integration with existing products.

At WWDC22, we said, "The focus of future protocol features will be declarative device management." And we are following up on that for this release with, "The focus of new protocol features is declarative device management." This release has new and compelling features that are only available via declarative device management. These include features that provide more parity with MDM and help with transitioning from MDM. First introduced at WWDC21 and enhanced with more foundational capabilities at WWDC22, declarative device management has generated a lot of excitement amongst MDM developers and enterprise administrators.

Several MDM developers have already implemented and shipped MDM servers with declarative device management support.

With the new features in this release, even more will want to do so to provide their customers with an enhanced management feature set.

Please review the sessions from WWDC21 and WWDC22 for an in-depth look at what declarative device management is and how to adopt it in your products.

A quick update on platform support.

MDM and declarative device management are now available for watchOS.

Full details can be found in the session "Meet device management for Apple Watch." Declarative device management is a collaboration between many different teams within Apple, aiming to provide robust and secure solutions for MDM developers and enterprise administrators.

Our focus is always on providing a seamless user experience that protects the privacy and security of users and their devices, while giving administrators the tools needed to protect enterprise data and to enforce compliance with policies.

It is also a collaboration with MDM developers and enterprise administrators.

Your feedback has helped us prioritize the features we are delivering in this release.

With the foundational elements of declarative device management now in place, our focus has moved to implementing core management features. Let’s examine what those are. First, is a new way to enforce software updates. Second, is managing apps.

Third, is securing devices by locking down system services and monitoring background tasks.

That is followed by installing certificate and identity credentials for use on a device. And finally, a new behavior to make transitioning profiles from MDM to declarative device management easier.

In partnership with our software update team, we are bringing a new managed software update experience to macOS, iOS, and iPadOS devices built on declarative device management. I.T. administrators need to ensure their users’ devices have the latest system software updates installed to guarantee required features and fixes are in place. Administrators need to enforce software updates, as well as defer them for a short period of time to allow the new OS release to be tested to ensure it is compatible with organization apps and services.

They also need to verify that devices have been properly updated when commanded to do so. For large fleets of devices, this can be a time consuming task. Today, administrators can use MDM commands to install updates on supervised devices. They can receive feedback on the state of an update when the server polls the device.

Administrators can also defer minor and major updates via profiles, preventing supervised devices from offering software updates to users during a specified period of time. But based on your feedback, we want to improve the overall managed software update experience for both administrators and users.

Declarative device management is the mechanism to provide administrators more control over the update process and give users a more informative experience, while also ensuring updates happen in a timely fashion. Here’s how.

Configurations can be used to define software update behavior. The device can proactively carry out those instructions, while keeping the user informed of the update process and giving them the opportunity to do the update themselves ahead of any deadline.

Predicates can be used to power sophisticated logic to control the ordering of software updates as devices get upgraded to seed and GM builds or as rapid security responses become available.

And asynchronous status reporting keeps the administrator up to date with the software update flow so that issues can be quickly resolved if they arise. Let’s examine how this is implemented.

A configuration has been added to manage an enforced software update of a supervised device by a specific time. There is also a set of new status items that report on the software update flow on the device, including details of the installation state and any failure reasons. Let’s study some examples.

This example configuration enforces a software update for a specific OS version and build at a specific time. The TargetOSVersion key indicates the OS version that the device should update to.

The optional TargetBuildVersion key allows targeting specific seed builds if needed. TargetBuildVersion will take precedence over TargetOSVersion if both are set. If no update is found for the specified version, the device will search for the default update vended by Software Update servers.

The TargetLocalDateTime key specifies a local date and time at which the update will be forced.

Here is an example status report for softwareupdate status items.

The install-reasons status item is an array of reasons describing why an install happened. This includes showing whether the update was initiated by a declaration, the system, or the user, or any combination of those.

The pending-version status item indicates which software update version the system is trying to install.

The install-state status item identifies what state the system is currently in with respect to the update.

The failure-reason status item specifies the count of any errors and the reason and timestamp for the latest error. Let’s examine what this looks like from the user’s perspective.

Users will be able to clearly identify what update is being enforced and by when.

They can easily choose to update ahead of the deadline or schedule it for that night.

If a user chooses "Update Tonight," the update will be downloaded and prepared, and then queued to update that night when the device has enough charge and is sufficiently inactive.

If the user doesn’t immediately trigger the update, then Software Update will post an Updates Available notification every day until the deadline. On macOS, the user has the option to choose "Install" or "Try Tonight" when the notification appears. 24 hours before the deadline, this notification appears hourly and ignores Do Not Disturb. One hour before the deadline, the notification appears every 30 minutes, and then every 10 minutes.

Let’s say the user had their device turned off because they were on vacation, and as a result, the deadline was missed.

When the user restarts the device, Software Update will post a notification telling them an update is past due, and the update will be tried within the next hour.

A similar experience happens on iOS and iPadOS.

Here, an administrator is enforcing an update to iOS 17.0, as shown in the highlighted section at the bottom.

The user can easily choose Update Now or Update Tonight, ensuring the update installs ahead of the deadline, just like macOS.

And like macOS, reminder notifications will be sent on an increasing cadence if they choose not to trigger the update themselves. And the same past due behavior will occur.

Software update declarations and MDM commands and profiles can co-exist.

However, software updates enforced by declarations will always take precedence over MDM commands and profiles.

The software update configuration and status items are available on macOS, iOS, and iPadOS.

Now let’s turn our attention to another important aspect of managing devices: Apps.

Administrators are required to manage the licensing, installation, updating, and removal of apps on managed devices. This includes providing support if problems arise and re-provisioning devices as they are assigned to different users with varying roles in the organization.

MDM developers provide a variety of tools to help administrators manage apps, making use of the MDM app-related commands and using Apple server APIs to look up app metadata and manage licensing.

The imperative, polling nature of MDM means administrators often struggle to respond in a timely fashion when problems arise, or when users change roles, or devices need to be cycled between users. Also, users have their devices react slowly when they first set them up or make changes.

Declarative device management can provide administrators with a new, more efficient experience when it comes to managing apps, and also provide users with a more responsive and reliable experience. Here’s how.

Configurations can be used to specify an app that can be available on a device when needed. They can be sent to the device ahead of time so that they are already present when device conditions dictate their use.

Predicates can be used to power logic to control which sets of apps are available to which users, based on device status or management properties set by the server. So administrators can quickly switch between sets of apps as needed.

An app can be shown to a user without it having to be installed, so that the user can choose when to install it, without the need for server intervention. This also avoids the need for intrusive user consent prompts. And asynchronous status reporting keeps the administrator up to date with changes to managed apps so that issues can be quickly resolved if they arise.

Let’s examine how this is implemented.

A configuration has been added to manage the installation, update, and removal of an individual app. There is also a new status item that reports on the list of managed apps.

Apps can come from the App Store or be enterprise apps specified by a manifest, similar to MDM.

On macOS, packages are supported, but they must contain only a single app. Also, app installs can be marked as optional to be triggered by the user. Let’s study some examples.

This example managed app configuration will install the Pages app from the app store.

The install behavior indicates the app is required. That causes the app to be immediately installed and managed when the configuration is activated. The app will also not be removable by the user.

Alternatively, the install behavior can be set to “Optional.” When the configuration is activated, the app is made available for the user to download when they want it. The user will also be able to remove the app whenever they want.

Other attributes to control management are present in the configuration, such as per-app VPN.

This example shows a status item for the Pages app that has finished installing.

The Identifier key is the unique identifier for the status object and is set to the app’s bundle identifier. The declaration-identifier key is the identifier of the configuration that is managing the app. The status updates asynchronously as changes are occurring on the device, so polling is not needed. Now let’s turn our attention to the user experience. Many MDM developers provide an app that gives users options for controlling the management experience. Often, a list of apps is present to give users the choice of what to install and when. Users can tap on an app to trigger its installation. To implement this, a private protocol is needed between the app and the MDM server to convey the list of apps, and then send actions from the user back to the server. The server has to then send an MDM command to trigger the install. All this back-and-forth introduces additional latency into the user experience. We want to improve this by making optional app installs simple and fast, while remaining secure.

A new managed app distribution framework is available for third party management app use. An entitlement will be required to use it, and that can be applied for as part of the App Store submission process. The framework contains a SwiftUI view extension that exposes each managed app as a SwiftUI view that can then be placed in a customizable layout. Users can view details of an app and tap to install. This improves the user experience by removing the roundtrip latency to the MDM server, allowing the app to be immediately installed, and also by providing better feedback on progress. Let’s examine what this might look like in an app that you could build.

This slide shows an MDM management app on iOS, using the new view service to show a list of apps to the user.

One app is currently installed. One is downloading, showing live progress. And another is optional and waiting to be installed. The style of the app view is customizable and, in this case, uses a standard list style.

On macOS, a more expansive layout can be used, such as the grid layout shown here, using a different style of app view.

The app using the view service can sort and group the set of apps in whatever way is appropriate.

If you already have a management app that shows an app list, this view service can be used as an alternative and provide users with a better experience. If you are planning on providing a management app, this view service will give you a head start to implementing it.

Note that if you intend to use the optional install behavior of the new managed app configuration, then you must provide your own management app for users.

The management apps configuration and status item, public framework and view extension, will be available for macOS, iOS, and iPadOS.

Additionally, as part of our goal to improve the experience of managing apps, I am pleased to announce a new "Apps and Books for Organizations" server API, available for immediate use.

This replaces the existing contentMetadataLookup server API.

The new API provides new customization and versioning features, in addition to better performance and uptime. Please visit the developer.apple.com site for full details of using the new API.

Now let’s examine how declarative device management can be used to help enforce and verify security compliance for macOS system services and background tasks.

Administrators are often required to ensure the devices they support behave in a consistent and secure manner.

Ensuring consistency means that it is easier to support a large fleet of devices, given that they are all configured in the same way. Ensuring compliance means that devices are known to have a base level of security, providing assurances that organization data is secure.

And when changes need to be made across all devices or when new devices are added to the inventory, this needs to be done in a quick and efficient way.

One part of this requirement involves configuring and monitoring system or third party services installed on a device.

macOS ships with many system services that are controlled via system configuration files. For example, sshd is configured via the files in the directory /etc/ssh.

Many of these system services must be securely configured by the administrator to guarantee the consistency and compliance required by the organization. Thus, it is important to ensure users cannot deliberately or inadvertently change these system configurations.

However, this is hard to achieve, as users often have the ability to modify the system configuration files or override the system service to use a custom configuration file.

Declarative device management is ideally positioned to provide a secure and reliable mechanism to support the configuration of system services protected by System Integrity Protection and provide a means to monitor background tasks to help guarantee device consistency and security compliance. Here’s how.

Declarative device management configurations can be used to specify sets of tamper-resistant system configuration files for different system services. Status can be used to monitor background tasks as they come and go.

And predicates can power sophisticated compliance rules triggered off device state, in a purely autonomous manner if needed. Let’s examine how this is implemented.

A declarative device management configuration has been added to support managing system service configuration files.

The configuration references a data asset that provides a ZIP archive.

When the configuration is activated, the archive is downloaded and expanded into a tamper resistant, service-specific location.

This location can be programmatically found by calling a function in a new library so that any system service can adopt managed service configuration files.

Built-in system services will be modified to look for the managed service configuration files and always use those ahead of any default or overridden system configuration.

Third party services can also adopt managed service configuration files in the same manner. We encourage you to contact developers of any third party services you use and have them adopt the new feature. Let’s examine how this works.

This example configuration will install managed service configuration files for the sshd service.

It includes a reference to a data asset.

Here is the example data asset.

The asset type is a new type and is used for conveying arbitrary data.

Also new is a way for assets to indicate what type of authentication is used when retrieving the asset data. This allows greater flexibility in where assets are hosted and how authentication and authorization is achieved to securely access the data.

The data URL in the asset points to a location where a ZIP archive file can be downloaded when the referencing configuration is activated.

The archive is expanded into a tamper-resistant, service-specific location, where the sshd process can access it and use it as its managed service configuration.

The first built-in services to adopt this feature are: sshd, sudo, PAM, CUPS, Apache httpd, and finally, bash and zee shells In addition to locking down system service configuration, this release also adds a new status item that reports the list of installed background tasks.

This allows administrators to quickly verify that required tasks are running and that unwanted tasks are not running. Let’s examine what this looks like.

This example shows a status array item for a background task. The details include: The unique identifier of the task. The uid of the user account running the task. Its state. The type of task, which is either daemon, agent, login item, app, or user item. Also available are any launchd details, such as label and program arguments, as well as a checksum hash of the launchd properties used to load the service.

Additionally, this release adds a status item to report on the FileVault enabled state of the macOS boot volume. It returns a boolean value to indicate whether FileVault is enabled or not, and it is easy to use in an activation predicate, so that security sensitive configurations can be installed only when it is safe to do so.

With this combination of managed service configuration files, background task, and FileVault status reporting, administrators now have a powerful way to ensure consistency and compliance across all macOS devices in the organization. Now lets discuss security certificates and identities in declarative device management.

Administrators need to ensure secure access to organization resources hosted on internal and external networks.

Often this requires adding certificates and identities to devices to ensure transport layer security or authenticated access to app services.

Different app services may use the same certificate or identity, and it is important to be able to manage such relationships.

Certificates also have a finite lifetime, so there needs to be a reliable way to refresh them.

Also, it is desirable to replace password authentication with secure technology, such as passkeys, which are faster, easier to use, and phishing resistant. It is thus critical for MDM developers to provide a reliable and efficient way for administrators to manage certificates and identities.

MDM already includes profile payloads that can be used to create certificates and identities in the keychain on devices.

It also supports provisioning identities via the ACME and SCEP protocols and supports retrieving certificates via a certificate list command. But there are some limitations on what MDM can do.

MDM certificate or identity payloads can be referenced by one or more other payloads within the same profile.

However, references to certificates or identities in other profiles are not allowed.

This means profiles either have to become larger to accommodate all payloads referencing the same item or certificates and identities have to be duplicated across multiple profiles, which means more work to keep them up to date.

Also, when a certificate or identity does need to be refreshed, all the other payloads in the profile will be updated in the system, which can be disruptive to the user experience.

Declarative device management can provide a more efficient mechanism for managing certificates and identities by utilizing the full power of its declaration data model. Here’s how.

Certificates and identities can be defined as asset declarations, and configurations can reference those assets.

Multiple configurations can reference the same certificate or identity, and multiple certificates or identities can be referenced by the same configuration.

And only the asset needs to be updated when the certificate or identity needs to be refreshed. This combination of assets and configurations resolves many of the limitations of MDM profile payloads.

In addition, status for certificates and identities can also be reported, including providing quick feedback when ACME and SCEP identities are provisioned without the need for polling. Let’s examine how all this is implemented.

A set of assets has been added to provide certificate or identity data.

Certificates use either the PEM or DER data formats.

Identities use the PKCS #12 format, or can be provisioned via the ACME or SCEP protocols. This includes use of hardware bound keys where available.

A new status item is also available to report on each certificate or identity installed via assets. Let’s study some examples.

This example asset will install a certificate.

The reference details provide a URL that delivers the actual certificate data to the device.

Another example shows an asset to provision an identity via an ACME server.

In this case, the reference details provide a URL that delivers a JSON document containing the properties needed for the ACME protocol exchange. Here is an example of the ACME properties JSON document.

The directory URL specifies the URL of the ACME server. There are a set of properties that define what type of key is generated and a set of properties for the generated certificate.

Now, lets look at the status. This example shows a status array item with two certificates. Each item includes the declaration identifier of the associated assets, as well as the DER encoded certificate data and an indicator of whether the certificate corresponds to an identity.

Now that we have assets for certificates and identities, we can make use of them in some new and existing configurations.

First, we have two new configurations that can be used to install stand-alone certificates and identities. Both reference a credential asset to provide the actual certificate or identity data.

The certificate configuration installs a single certificate into the keychain. If the certificate is self-signed and is a certificate authority, then it will also be added to the trust store.

The identity configuration installs a single identity into the keychain.

These configurations are available on all platforms.

Next, we have a configuration for deploying enterprise passkeys.

WWDC22 introduced passkeys as a solution for eliminating the use of passwords on websites and in apps. In this release, our focus has turned to making passkeys easy to deploy in the enterprise by ensuring that only authorized devices and users can provision them.

To support this, there is a new enterprise passkey attestation configuration that can be used to securely generate a passkey for a user on a device when they visit any site specified by the configuration.

The configuration references an identity asset.

The identity is then used to perform a standard WebAuthn attestation of a generated passkey.

The WebAuthn relying party can then verify this attestation and allow access to the relevant sites. Thus, administrators can restrict certain passkeys to only managed devices.

This feature is available for macOS, iOS, and iPadOS.

Details of how the MDM server and relying party work together to implement this flow can be found in the session "Deploy passkeys at work." Finally, the Mail and Exchange account configurations have been updated to support S/MIME to bring feature parity with their MDM profile payload equivalents.

The configurations can now reference identity assets that can be used for S/MIME signing and encryption. This is available for iOS and iPadOS.

For our final item, let's discuss a new behavior that makes it easy for you to transition from MDM profiles to configurations.

Declarative device management is built into MDM and can be used in parallel with MDM to add new management capabilities, allowing you to transition your products over time.

Implementing declarative device management in MDM is as simple as sending the MDM DeclarativeManagement command to the device, and syncing over a set of declarations that get activated on the device.

Then the server listens to incoming status reports.

To make this transition easy, a legacy profile configuration was created to allow existing MDM profiles to be sent as a configuration, enabling profiles to take full advantage of the autonomous and proactive behavior of declarative device management.

Doing that involves first removing the existing MDM profile, then sending and activating a configuration that installs that same profile.

This can be a disruptive process, causing things like accounts to have to refresh all their data, or leaving a management gap in which restrictions are missing from the device for a short while. MDM developers have asked for an easier way to transition from using MDM profiles to the legacy profile configurations. And now this is possible. Here’s how. Declarative device management now supports taking over management of already installed MDM profiles without the need to remove them. To use this, all a server has to do is send and activate a configuration that contains the same profile as one already installed by MDM. The declarative device management system will then take over management of that profile without reinstalling or updating it. At that point, declarative device management owns the profile. MDM will not be able to make changes to it.

There is no disruption to the device state the profile is managing. And there is no management gap. This makes it much easier to transition from MDM to declarative device management.

This new behavior is available on all platforms.

That concludes the last of our agenda items covering the exciting new features we are bringing you for this release of declarative device management. Now let’s wrap up. With the foundational elements in place, this release has focused on building out key management features using the power of declarative device management.

Many of these features are the results of requests received via your feedback, and we thank you for that.

As declarative device management continues to advance, we welcome more feedback to help us prioritize the features that are important to you.

With new management features being added only to declarative device management, it is now critical for you to build support into your products if you have not already done so. If you already have support, the new features in this release will give you even more opportunity to make great products your customers will love.

Information about other new management features in this release can be found in the session "What’s new in managing Apple devices." The schema for new configurations, assets, and status items is available in our open source schema repository, which you can find linked in the session reference details.

Thanks for watching. ♪ ♪