Share This Article
Last week, Apple released beta versions of the macOS Ventura operating system for desktops and the iOS 16 mobile operating system for mobile devices. What does the iOS update mean for MDM?
That’s exactly what a friend in the Mac Admin community asked me recently. I thanked them for their candor and request as many of us have yet to dive into Apple’s MDM documentation.
So, I rolled up my sleeves and got to it. Keep reading for an overview of what types of changes you can expect and how to optimize your mobile device management strategy.
Reading Apple Docs
Let’s start by talking about how we derive these changes — reading Apple’s Documentation:
Apple has a fantastic documentation system that clearly shows what’s changed between major and minor releases of macOS and iOS. Check out the key in the upper right hand corner of the documentation page:
Select the value Xcode 13.3 to Xcode 14.0 beta 1 to compare between the current version of macOS Monterey and the beta version of macOS Ventura.
Apple uses symbols and colored outlines to indicate change:
Purple Outline, ~ character: there is a functional change in this object.
Green Outline, + character: there is an additional behavior or setting.
Red Outline, – character: there is a deprecation in this object.
Check out the example below:
Furthermore, Apple is now releasing some additions, like the ACMECertificate Payload, in Beta. Beta payloads may not work like you think, or at all, depending on implementation.
Changes to the MDM Profile Keys
Most notably, Apple has massively changed the SystemPreferences policy that has been around since macOS 10.7 Lion. This restriction allows admins to hide individual Preference panes from the end user, but with the advent of the new System Settings app, this configuration is currently deprecated.
Translation: if you’re hiding Preference panes from your users, you will need to file a Feedback with Apple to get a new management configuration.
This is the only deprecation in the Profile-Specific Payload Keys section. But Apple has updated several policy keys, some of which are incredibly exciting (especially to JumpCloud)!
Let’s review the Documentation section by section.
Authentication
First up, are changes to the keys for Extensible SSO, first released with macOS Big Sur. These are additions, including two new keys that will help power the Platform SSO feature:
AuthenticationMethod and RegistrationToken, both of which are used by your IDP’s Platform SSO Extension. These keys allow admins to use either passwords or hardware-backed elliptical curve certificates to handle device authentication to the IDP.
In addition, the Kerberos version of the SSOE will now support falling back to Platform SSO, allowing you to use IDP-backed authentication if Kerberos TGTs are unavailable at the time of authentication.
Certificates
Solving the chicken and egg problem related to how to generate the right kinds of device trust has always been a challenge. The old SCEP method of generating certificates that all sides can trust actually predates TLS encryption, so having a replacement for a new era of certificates sounds pretty dandy.
Apple has decided to support the ACME protocol, which originated out of Let’s Encrypt’s CA infrastructure. Based on JSON objects transmitted over TLS, this is a better way to a) get some certs on your devices and b) use them with your own apps and services to keep your environment secure.
These ACME certs are also at the core of Apple’s new Device Attestation framework for iOS, iPadOS, and tvOS. Undoubtedly, Apple has produced some incredibly secure ways of proving device and user identity to a given service. This includes certs backed in the Secure Enclave of devices that generate private keys, but can never be exported. This new framework has the potential to revolutionize Zero Trust postures in your organization and prove that devices are legitimate at authentication time.
Networking
One of the hardest things for anyone to do in 2022 is understand when to use IPv4 instead of IPv6. Knowing how to handle the translations between IPv4 to IPv6 and back again is equally challenging. The same is true for our cellular carriers. The good news is a new setting will allow admins to set APNs to include 464XLAT, which translates back and forth between IPv4 and IPv6 and back again. This is a big feature for some diverse carrier groups, and one of those if-you-know-you-know sort of things.
Proxies
Apple Devices have supported the configuration of proxies via MDM configuration profiles, including Global HTTP Proxies, and a Network Proxy Configuration, as well as DNS Proxies. Making sure network traffic goes where admins direct it is an important task for any device. Apple now supports using a DNS Proxy just for individual apps by specifying the UUID of the new configuration within the app management dictionaries during installation.
Note: Check out our MDM simulation to learn more about our MDM configuration settings.
Restrictions
The all-important Restrictions dictionary is a one-stop shop for a whole lot of policies that an admin might want to control on a device. This year’s change is the addition of a new key, allowUniversalControl. If set to false, this will prevent Universal Control between devices. While orgs that are using Managed Apple IDs at work are already doing the hard work of preventing this feature – Managed Apple IDs don’t support the iCloud Keychain necessary to allow this feature’s use – those that are allowing personal Apple IDs at work may still want to prevent work data from leaking to personal devices through this conduit.
Web Content Filter
macOS 11 brought the Web Content Filter policy dictionary, along with the new System Extensions posture for using it. In this year’s releases, you can now distribute Web Content Filter apps to iOS devices. The result is more support for deploying a per-app configuration of the Web Content Filter dictionary using the ContentFilterUUID key.
What’s Left Unsaid
Apple made two sets of wholesale changes in macOS Ventura that are notably not included in the policy docs for this year’s OS so far: User-Approved “Login Items”, and System Settings Pane Restrictions.
As of beta 1 of macOS Ventura, it’s not currently possible to hide a given LaunchDaemon or LaunchAgent from the deft fingers of your coworkers on their devices. This means admins and standard users can deactivate IT tools like EDR/XDR, Update Mechanisms like Nudge, and even system agents like JumpCloud’s own agent.
This is highly undesirable — even if I can put myself in the shoes of a product manager at Apple and understand why they did it. Hint: it’s to dull the effects of malware and quasi-malware that seeks to annoy the end user.
If you haven’t yet, as an Apple Admin, login to your Appleseed for IT account in Feedback Assistant and file some feedback about this issue. Admins should get control over the LaunchDaemons and LaunchAgents that they install; users shouldn’t be able to tamper with that.
In addition, you cannot currently block user access to key areas of the System Settings app, due to the deprecation of the old System Preferences app, and its associated MDM restrictions.
You might not want, for example, to show the Profiles pane to your users, lest they do untoward things to MDM enrollment profiles, or you might not want them to allow the setup of new VPNs. Putting the user in charge of settings can lead to misconfigurations, and misconfigurations lead to bad experiences, security compromise, and worse. This one also belongs in the hands of admins.
Changes to MDM Commands
The MDM Command structure is still being developed, but I would largely say that the version 1 features of MDM are nearing maintenance mode. Future development may be focused entirely on Apple’s new Declarative Management suite of protocols. There have been a few updates to the MDM Commands we’re all familiar with.
Installing Apps
Apple has added new features to iOS apps over the years, including recent innovations like App Clips. Users can enjoy these partial apps in lightweight modes, like at the gas pump to pay without having to download a whole app, or the same experience at a restaurant.
Apps like this haven’t been differentiated from whole apps to MDMs until iOS 16. In addition, other tell-tales like per-app VPN, Beta apps installed with TestFlight, a flag to indicate an update is available… there are loads of great options here for MDM manufacturers to mine for better user experience.
Getting Device Information
Another key task of the MDM is to retrieve information from the device and display status information to the admin. Notably, there have been deprecations of major items in here, including key identifying information, like the ICCID, IMEI, Current Carrier Network, and Phone Number.
These values have been double-counted for a few years now, and the main instance is gone, in favor of these items being returned in the ServiceSubscriptions query instead. This makes all the sense in the world in a world where eSIM is available now on most iOS devices.
Starting with iOS 16, you’ll also be able to read information about accessibility settings for a given device, to understand how your coworkers are using their devices in the field. This is a great way to understand how your coworkers are actually using the devices that they have and will represent a great way to improve your own IT posture as a result.
In addition, Shared iPads can now report back which Managed Apple ID Domains are currently assigned to the device, as well as the current grace period for user authentication.
Install & Query Apps on Device
As mentioned above, iOS now supports Web Content Filters and DNS Proxies, so the UUID of the connection can now be included during the managed installation of individual apps. This powers the per-app connectivity of managed apps with managed security tools and profiles. You can both specify this during install and query the state of the connection during further queries.
Settings Commands
Apple has added the ability for an MDM to set the Accessibility settings of any Apple device, including the ability to set Bold Text, Increase Contrast, Reduce Motion, Reduce Transparency, and enable key accessibility settings like VoiceOver, a built-in screen reader, Touch Accommodations, and the ability to Zoom in.
These are unique settings for the MDM world, since they are very similar to the “Set Once” feature of the old-style MCX preferences that Apple used to use. This will give Admins the ability to set a device to a given state, and then allow the user to override those settings to meet their own needs, instead of locking them to a stated value.
Declarative Management
Of course, no discussion of the MDM releases for 2022 can leave Declarative Management off the list. Apple released a substantial amount of detail around their Declarative Management model at WWDC this year, including a 30-minute video on adopting Declarative Management.
The company announced the new management model for Apple devices at WWDC 2021, with a testing version of the protocol available for User-Enrolled iOS Devices. In 2022, Apple now supports declarative management for all enrollment types, from device-enrolled, to automated device enrollment, to user-enrolled to Shared iPad, across all of its device families.
This new device-driven desired-state management protocol is something that admins and MDM manufacturers alike can learn more about over the course of the summer ahead of its formal arrival in the Fall, and eventual adoption. We’ll have a lot more to say about Declarative Management in the future.
Conclusion
Apple has made some welcome changes to the MDM specification. Unfortunately, there are also a few confusing changes that have left gaps in the management framework we all know and tolerate.
If it’s essential for your organization to manage some of these missing features, it’s crucial to file Feedback with Apple. Include an impact statement and explain how this missing feature might block your adoption of the new operating system features.
Happy testing, everyone!
