MDM-capable, MDM-enabled, or MDM managed users - why to not use user level configuration profiles

[rabbitt]

tl;dr - Getting an "MDM-enabled user" and user channel for configuration profiles has become unobtanium.  Pretend that macOS is like i[Pad]OS where all configuration profiles and certificates are scoped to the whole machine.

"Managed Users"

A user who is "MDM-capable," "MDM-enabled," or in the Apple MDM spec a "managed user," can be achieved in a few ways:

• First user created by Setup Assistant when machine is first set up via automated device enrollment
• A user with administrator rights initiates a user enrollment via an enrollment URL or renewing the automated device enrollment with a profiles command
• Mobile accounts (aka bound to a directory service) where during login there is a token registration with the MDM.

For reference, see Enabling MDM for Local User Accounts and from apple.com Prepare for changes to kernel extensions in macOS High Sierra

For a configuration profile or a certificate to be issued to a single user account on a Mac, the user must be a "managed user" as of macOS Catalina.  For administrators used to binding their Mac to AD and having this user channel, the change will require planning and changes.  (Useful related story: User vs. Machine Certs on MacOS) 

What Jamf Connect does with local user accounts

Jamf Connect is MDM agnostic and exists outside of the initial SetupAssistant DEP experience. It is creating accounts just-in-time after the MDM process of device enrollment is complete. The account created is a local account (not bound). Thus, per Apple's specifications, it is not a "managed user." Changing a local user’s MDM capability requires the MDM profile to be re-installed or re-enrolled, which can affect User-approved MDM status if attempted programmatically. Re-enrollment may not be possible in future versions of macOS, limiting this further. Refer to announcements from Apple made at WWDC2020 regarding programatic installation of profiles and future releases.

How to get a "managed user" and use Jamf Connect

An alternative workflow can achieve a managed user and use Jamf Connect for ongoing password sync. Use an Enrollment Customization (available with macOS 10.15 and above) to create the initial user account.

• Set up Single Sign-On in your Jamf Pro server - Jamf Pro Admin Guide and select the option to "Enable Single Sign-On for User-Initiated Enrollment"
• Create an Enrollment Customization containing the Single Sign-On payload - Jamf Pro Admin Guide
• Create a Prestage Enrollment - Jamf Pro Admin Guide with the following payload options
• In the General payload, select the Enrollment Customization Configuration option for the Enrollment Customization you created with the Single Sign-On pane
• In the Account Settings payload, select the option for "Pre-fill primary account information" where Information Type is set to "Device owner's details" and select the option for "Lock primary account information".
• OPTIONAL: Select the "Create a local administrator account before the Setup Assistant" and create an administrator user which will unlock the settings for "Local User Account Type". You can make the first user a Standard user here and later elevate the user permissions with a Jamf Pro policy or the SAP-enterprise-privileges application.

The user created will be a "managed user" per Apple's MDM spec. From there, we can use Jamf Connect to keep that user's local password in sync with an identity provider.

After the user has logged in, scope a configuration profile for Jamf Connect to the target machine and run a Jamf Pro policy to install the Jamf Connect and Jamf Connect menu bar launch agent installer packages.

In this scenario, you may want to disable the Jamf Connect login screen as modifying the managed user in any way may lose the managed user state. Experimentation in your environment will be important. The Jamf Connect menu bar agent can be used exclusive of of the login option to keep the local user password in sync.

How to move an existing user to "managed user" status

Note: If a user is not am MDM-capable user, and an administrator wants to make them MDM-capable, run the following command AS THE USER ACCOUNT 

sudo profiles renew -type enrollment

This can also be accomplished with the "sudo profiles -N" command which is a direct replacement in the current macOS but subject to being deprecated in a future version of macOS.

The user being modified must be:

• An administrator on the machine
• Must interact with the System Profiles application to "reenroll" the machine via automated device enrollment
  • This means that if SSO or login to the MDM server is required, the user will need MDM server permissions for enrollment and re-enrollment.

The machine must be enroled in Apple's automated device enrollment via Apple School Manager or Apple Business Manager and must be assigned to a prestage in the MDM server.

Feedback to Apple around managed user and user level profiles

If you would like to submit feedback to Apple about this process, log into feedbackassistant.apple.com with your Apple Business Manager or Apple School Manager Apple ID to tie the feedback to your organization's ASM/ABM account.  Refer to the following already submitted feedback assistant request:

FB9899085 - Feature Request: Allow for a local user account to become “MDM managed” outside of the context of initial MDM enrollment

[vcherubino]

I still haven't been able to get this working. I have the SSO Enrollment customization, but I pass the info to Jamf Connect for the account creation. I'm guessing this bypasses what is needed to get the user account MDM enabled, but I prefer this method.

[rabbitt]

The command

sudo profiles renew -type enrollment

 didn't make the user MDM enabled?

[vcherubino]

It does, but it also kicks off our full enrollment, DEPnotify and all, and starts re-installing software. It fails DEPnotify at first requiring a force close of the DEPNotify window and then tries again "successfully". The UX would be terrible.

Easier to just avoid user level profiles in general.

[rabbitt]

Look for policies triggered on “Enrollment Complete” and change the scope so they only apply to computers coming in via prestage and not via user enrollment.

[PhillyPhoto]

Do you have specifics on how to scope to this?

[fsjjeff]

I'm IT for a school board that does 1:1 with ~6000 iPads and ~2000 Macs - and just running into this issue.  But worse for us as MDM Enabled users are absolutely required to be able to push out the Classroom EDU settings.  It worked fine for years with our Active Directory Mobile Users, which we've used up to now, but as we're slowly moving away from that (as per Apple's strong recommendations) it's breaking our Classroom settings. 

Needless to say I know have lots of pissed off teachers right now - ugh.

You can have multiple MDM Enabled users no problem if they're all Mobile or Network users (which pretty much requires AD binding that Apple says not to do anymore), but only 1 if it's a local user.  And there's no easy way to switch which user gets the MDM enablement due to Apple changes in MacOS 11.

I'm really starting to feel that Apple is developing these new 'features' isolated from each other and with no sense of best practices or how any of it works in the real world.  Personally after 15 years as an Apple district I'm just about ready to start recommending we investigate moving to Chromebooks cause the Apple way is increasingly "Just doesn't work (tm)"