The ins and outs of Apple identity management in the enterprise

It used to be simple: users had a local account on the PC that they used or they had a network account in Active Directory that could be used to login to their assigned computer or others  in the network. 

Adding Macs to the equation took a certain amount of work, especially if you wanted to manage those Macs. But Apple’s adoption of Active Directory support in Mac OS X Panther in 2003 made the process both doable and reasonably straightforward. 

Things are different today — the migration of virtually everything to the cloud has opened up new opportunities from authentication to single sign-on access to cloud applications to user and device management. Not surprisingly, one of the biggest challenges is integrating all these cloud services in a coherent way. 

That challenge isn’t specific to Apple devices by any means. Users and the services that support them (including MDM) do rely on multiple services that need to be integrated as part of an enterprise IT infrastructure.

Exactly what that means and how best to go about that integration can be confusing, especially when it comes to the Mac.

Directory service binding

Macs have long been able to be joined (bound) to Active Directory. There was a time when Apple maintained its own directory service (Open Directory) that was LDAP- and Kerberos-based like Active Directory. Apple’s directory service support allowed a Mac to be joined to a Mac server hosting Open Directory and/or an Active Directory domain. 

Apple deprecated its own directory service and then canceled it altogether when it discontinued macOS Server. But the underlying directory service support still exists in macOS, meaning you can still join a Mac to Active Directory (or another LDAP system). The process will work for authentication but no longer supports Mac management as it once did – that functionality has long been transferred to MDM. It is also considered a legacy technology so modern-day organizations should rely on more modern options. 

The differences between macOS and iOS (and iPadOS, tvOS and visionOS)

It’s important to understand why macOS is a different beast than other Apple platforms. Modern macOS has always been designed as a multiuser system that continues to support local accounts.

iOS (and its descendants) is not designed as a multiuser system; mobile devices are designed to be used by individuals – one person per device (the exception being shared iPad). iOS is designed to rely on a user’s Apple Account for the principle identity rather than local or network user accounts. It is also designed to rely solely on MDM for device management. (While there is support for accessing multiuser systems such as email and calendaring, even those configurations are designed to support a single user.)

So, while there are more options for working with Macs in an enterprise environment, the methodology that creates those options also creates headaches that are sidestepped on other Apple devices. 

Federating and Apple Business Manager

Apple Business Manager is designed to be the primary management tool for Apple device and identity management. It maintains Apple device inventory, manages device assignments (and/or ownership) for users, handles app licensing (for any App Store titles), controls managed Apple Accounts, connects to MDM and federates with identity providers for authentication and authorization tokens. It also syncs user account data with those identity providers to handle managed Apple Accounts.

At this point, Apple Business Manager can federate with the major identity providers, including Microsoft Entra, Google Workspace, Okta, and Ping.

Managed Apple Accounts

Apple Accounts handle a user’s identity across the Apple ecosystem, managing everything from device ownership to music and service subscriptions, health and fitness data, FaceTime, iCloud and family sharing. They’re the glue that makes Apple’s seamless experiences work across devices and enable Continuity features such as  universal control, handoff, continuity camera and sidecar. 

To square an Apple Account as the sole identity for most Apple devices with the need for enterprise identities, Apple created managed Apple Accounts in 2016 — and it’s worked to refine the tool in the years since. 

Managed Apple Accounts do almost all the things that regular, personal Apple Accounts do, but they’re created and paired with a user’s enterprise identity through Apple Business Manager. On an iOS device, they show up as a second Apple Account and can be used for account-based device enrollment in both BYOD and company-owned device scenarios. 

Federating Apple Business Manager with an identity provider enables managed Apple Accounts to be created based on a user’s enterprise identity/account (they’re typically named after their business email address). When properly connected, Apple Business Manager can create a managed Apple Account on a user’s first login or setup of an Apple device. Managed Apple Accounts can also be set up by hand – federation is optimal, but it isn’t strictly required.

One point of confusion is that while managed Apple Accounts aren’t exactly new, many of their functions – the ability to be created through federation and to support most Apple and iCloud services – are. As a result, many organizations that have long supported Apple devices are likely to have instances where devices were configured (and apps provided) using personal Apple accounts. 

This can mean two different things. Either a user set up their device using the same personal Apple Account they used in their non-work lives, or an organization created (or had the employee create) a personal Apple Account specific to work-related or company-owned Apple devices. 

Apple allows a personal Apple Account to be converted into a managed one —appropriate because the company account was always intended for work purposes. (This shouldn’t be considered an option when you’re talking about a truly personal Apple Account; in that case, creating a new managed account is a better move.)

It’s easy to see how managed Apple Accounts work with iOS devices since the only identities on the device are a user’s personal Apple Account (in a BYOD context) or a managed Apple Account for work. 

Shared iPad is a bit more involved. When an iPad is configured to be shared, individual users can sign in to use it if they have a managed Apple Account. iPadOS will partition the available storage so that each user’s preferences and data are separate. Functionally, however, the iPad will act as though if the managed Apple Account is the only identity once a user is signed in. That makes it a quasi-multiuser system rather than a full one seen with macOS, Windows or Linux. 

A Mac is a true multi-user system: each user has a local account and home directory as well as file system permissions that govern the drive/partition and any additional drives or partitions such as USB sticks. Those local accounts may or may not be tied directly to a managed Apple Account (or even a personal Apple Account). 

The result? There isn’t a single source of identity as there is on an iOS device. Even so, Apple still cites managed Apple Accounts as the best practice for Macs and other devices. 

Ideally in practice, the Mac will have a local user account that matches a user’s managed Apple Account. Some aspects of that managed Apple Account are defined by a federated identity provider; others are defined in Apple Business Manager. Identity for network authentication and the enforcement of policies such as passcode requirements and multifactor authentication are among the policies handled by the federated identity provider.

This works well sometimes — but it can create problems, too. 

Keep in mind that while Apple Business Manager uses an identity provider to create managed Apple Accounts when federated, the managed accounts aren’t stored by the provider. They reside in Apple Business Manager, which is capable of creating managed Apple Accounts and user/device assignments independent of federation. 

The big problem is when Macs are shared by multiple people. Each user ends up with a local account on every Mac that they log into — and since local accounts have local home directories and local preferences, users can end up with different files, settings, and other attributes on different Macs. (This can happen with shared iPads, but since the iPad OS file system isn’t truly exposed and focuses more on syncing with various services it’s less problematic.) Managed Apple Accounts do now support the major features of iCloud, including sync services, which helps somewhat, but isn’t a full-fledged solution.  

FileVault, Apple’s file and disk encryption, can also be problematic because a Mac typically requires a local user account to unlock FileVault on boot or restart — and that account needs the appropriate permissions to do so. Outside of work, this is less a problem; a user will typically login with an account that has sufficient privileges and isn’t tied to anything other than that particular Mac.  

Macs and single sign-on

Local accounts aren’t the only issue that can arise when using managed Apple Accounts instead of directory service binding. Single sign-on is another. When a Mac is joined to Active Directory, single sign-on is automatic and similar to a Windows PC with Kerberos powering the process. Users simply login with their enterprise credentials at the macOS login window. 

This is not an automatic feature for managed Apple Accounts – remember, these reside in Apple Business Manager and are synced with your identity provider when federated. Apple’s Platform SSO extension is intended to resolve this issue; it lets apps and websites support single sign-on via a federated identity provider and can be called at the login window or via an installed app. One advantage Platform SSO does offer is support for multifactor authentication.  

In practice, Platform SSO is not ideal. It’s designed for BYOD and one-to-one deployments where each user has his or her own Mac and doesn’t match as well as directory service binding for Macs that support multiple users. Although broadly employed, there may be situations where it isn’t supported. 

While Apple provides limited administrator tools for using Platform SSO, third-party vendors have created better implementations, including JAMF Connect, Kandji Passport, and SimpleMDM. These tools also simplify support for multifactor authentication and user access to a Mac, often replacing the standard macOS login window. But they also require another investment in cost, time and complexity.  

Identity and MDM 

Mobile Device Management (MDM) software interacts with enterprise identities through Apple Business Manager. Once the MDM setup is in place and connected to Apple Business Manager, it can access users, devices and groups available to Apple Business Manager and use them to provision devices and manage configuration profiles; handle user account assignments; and send MDM commands. (The data required for these functions is stored by the MDM service, not Apple Business Manager or any federated identity provider.)

In practice, this means several components need to interoperate to support Apple devices in enterprises. At a minimum, there’s the underlying identity provider, Apple Business Manager, and MDM solutions. Tools for managing Kerberos and single sign-on through Apple’s Platform SSO are best included, too, whether they are part of an MDM vendor’s offerings or something additional. 

Why so much confusion?

The main reason this can be so confusing is that Apple has been making things up as it goes. Managing identities was simpler when it was handled largely by Active Directory (AD). Then came MDM tools to complicate things, followed by managed Apple Accounts. Basically, Apple has had to follow the path created by cloud-based infrastructure, putting in place patchwork system rather than a consolidated vision based on today’s IT landscape. 

(Respondents to the recent Six Colors survey on Apple in the enterprise acknowledged that very issue; Apple has yet to resolve it.) 

So, where does this leave things?

Putting together a fresh setup to manage, secure and support Apple products in business environments begins with an identity provider populated with the requisite user information. This is then federated to Apple Business Manager, which uses that information to generate managed Apple IDs as users are onboarded and assigned devices (or who enroll their own devices). For Macs, a third-party tool, ideally one offered by a chosen MDM vendor, is installed to manage Apple’s Platform SSO. 

Starting with a clean slate, it’s a relatively straightforward process. But local accounts on Macs, FileVault, personal Apple IDs, users who work on multiple Macs and other legacy hangovers make everything much more complicated. The reality is that there will be patchwork of systems that must work together, regardless of whether you’re starting fresh or developing a modernization/transition project. 

Companies will be watching to see whether Apple can streamline things next week at WWDC; at the very least, let’s hope it doesn’t add even more components and complexity to the equation.