That is the question, the common question nowadays, not specific to the macOS world by the way. Windows offer the same alternate strategies (with more or less the same pros and cons for each answer).
Binding or not binding to a directory services is the main question that mobility first let us.
If you are an “old-style” system administrator used to bind your workstations to your directory service, this concern may seem bizarre. If you are new to this world, you might be doubtful looking at the two camps facing each other.
Let’s try to understand why you would choose one side or the other, through the prism of a macOS deployment with MDM and DEP.
The context
To start this journey through the device deployment and management style, we will start with few assumptions:
- your company use mobile macOS devices and need to manage those devices remotely;
- your company uses a Mobile Device Manager like Workspace ONE UEM or JAMF to manage those devices;
- your company has a central directory services like Active Directory;
- your company uses the Device Enrollment Program to streamline the Mac deployment workflow.
This list is more than few assumptions to be honest, if your current company miss one of these points, you are doing something wrong…
You are given the task to handle macOS devices in this context and are free to choose whatever you think is right for your company. No constraint to “do like you ever did.”
Setup pitfall
MDM Enabled User
This level of functionality is something you will need even if you don’t know it yet.
When a macOS device is managed by MDM, you’ve two levels of management:
- system;
- user(s).
System level will have specific payload available like energy saver settings.
User levels will be mandatory for e-mail accounts, user certificates and identities/certificates preferences for Single Sign On.
To understand this concept, you can imagine each level as boxes, apps can only access settings for the current box and the parents ones.
Each context has a push token allowing the MDM to send targeted commands and configurations. Alice’s app will have access to blue (Alice’s) and purple (system’s) settings, but not the orange (Bob’s) one.
FileVault with APFS
FileVault is a really good technology allowing full disk encryption with no performance lost on all Mac devices. It works really well and it’s super secure.
With APFS, Apple “improved” the FileVault technology making it even more secure, but less manageable.
When FileVault is enabled, a preboot login window is shown when the Mac start, before the system loading. This FileVault login window shows only FileVault enabled users.
Before APFS, the root user was able to directly grant a user for FileVault boot, with APFS, only an admin on the device can grant a new user. Only the first ever local account accessing the device gets enabled for free. All others will need approval from a local admin already allowed for FileVault.
The two scenarios
Binding
In this scenario, the IT team set up the computer first by following the setup assistant, enrolling the device to the MDM with the help of DEP, not creating any local users except the managed admin account provided by the MDM. The MDM will then deploy the directory’s settings and other kinds of systems related settings. The software catalog will also start to install all common app for your companies (directly from the login window if set properly).
When the user log in for the first time, the directory service must be available (that is to say, workstation connected to your internal network on the login window). Once connected, the directory identity is cached by the device and can be used outside.
Each time a user opens a session on the Mac, the login window will reach the MDM to provide the related push token generated for this user. Allowing the MDM to know who’s the current user on the device and push some related content to this user context.
One important point, the user access the computer with the company’s credentials. When the user change the password, the directory must be reachable and the password will be changed for all other bound services (VPN, mails, file sharing, etc.). It’s really the same identity used everywhere.
End user password policies will be managed directly by the directory service.
Enabling a directory user to pass the FileVault login will require an admin to grant the access with a local action one the device.
Reusing the device for another user will require:
- new user login
- FileVault enablement
- previous user deletion (to save system space)
Not binding
In this scenario, the end user will do the initial setup. IT teams should not be able to do it.
During the setup assistant, the DEP profile will ask for a directory authentification before enrolling to the MDM. This authentification will allow the enrollment and also associate the device to the user.
This is why the IT can’t do it for the end user (and no, IT must never know the end user password, your HR and legal department will explain to you why).
Once the enrollment is allowed, the setup assistant will offer to create a local session for the end user. This initially created local session will be the only one to be MDM enabled. The push token for this local session will be associated with the previously authenticated user.
Once this session is created, none other will ever have an MDM push token. You can create additional local user accounts, but none will be managed by the MDM.
When the setup assistant is done, the newly created session automatically open and software catalogs can start to install apps. It’s recommended to use tools like DEPNotify to add an additional “setup in progress” screen, avoiding the user to ask your help desk why Slack isn’t here…
FileVault will be automatically enabled for this first user.
The user account is local, linked to a directory identity from the MDM point of view. But not synced in any way. User names as well as passwords can be different.
Additional tools like Enterprise Connect (Apple software only available via Apple Professional Service) or JAMF Connect (previously known as NoMAD) will help to synchronize the identities by checking if the password is the same. But only after the passwords are changed.
The local user password policies will be managed by the MDM.
Reusing the device for another user will require to wipe the device and reinstall macOS.
Draw me a deployment
The same information across an operation line will be drawn that way:
Conclusion
We can’t conclude by saying “use A over B”, but we can extract few axioms from this article:
- not binding to the directory require single user devices that will be wiped when their attribution change;
- not binding to the directory requires the end user directory credentials to pass the setup assistant, so can’t be done by IT;
- binding to a directory is required for a multi user device;
- binding to a directory is required to fully prepare the device before distribution (and even assignment);
- it is more simple to deploy FileVault when you are not bound to the directory service.
In addition to this article, you can find a feature to feature comparaison on the MacAdmins Community Documentation.
