Migrate between MDM solutions

[noahtalerman]

Goal

As a user, I want to be able to migrate macOS hosts from my old MDM solution to Fleet so that I can use Fleet to remotely update macOS and enforce macOS settings.

Related

• Parent epic: #7726

• 7957

Child issues:

• 9009

• https://github.com/fleetdm/fleet/issues/9277
• https://github.com/fleetdm/fleet/issues/9278

• 9365

Requirements

1. IT admins do not have to perform any action on the host to migrate a host. They only have to unenroll the host from the old MDM solution.
   • For now, this requirement will only support Macs where the end user has administrator permissions. This means that Fleet won't have to handle this problem: If the end user has standard permissions (not admin) they can't install the new automatic profile (they don't have permissions).
2. UI for end users on how to turn on MDM if their host was automatically enrolled to the old MDM solution.
3. UI for end users on how to turn on MDM if their host was manually enrolled to old MDM solution. Most of the UI is covered in #7957
4. Fleet retrieves new bootstrap tokens.

Design

UI

https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=10517%3A316026

[noahtalerman]

UPDATE: I think I answered my own questions: https://github.com/fleetdm/fleet/issues/8153#issuecomment-1274820424 (noahtalerman)

@GuillaumeRoss @lucasmrod @michalnicp do you know the permissions around removing an enrollment profile (DEP and manual)?

My current understanding is that there these scenarios for permissions can occur:

1. Anyone (e.g. script) can remove the enrollment profile.
2. Only the MDM solution (e.g. clicking Unenroll in Jamf) can remove the enrollment profile.
3. Only the user (e.g. clicking Uninstall in System Preferences) can remove the enrollment profile.

Do you know when then scenarios happen? Am I missing any scenarios?

[noahtalerman]

cc @zhumo ^^

[noahtalerman]

I think I answered my own questions using this Apple doc: https://support.apple.com/guide/deployment/reenroll-devices-in-mdm-dep26505df5d/web

Scenario (1) might never occur. This is unanswered.

(2) occurs when the profile is nonremovable.

(3) occurs when the profile is removable.

[noahtalerman]

TODO Noah:

• Test unenrolling a manually enrolled host. We think you have to click minus on the user side.

Mo: Apple has to send down the DEP profile. Flow would work if we gave the user a script to run.

[noahtalerman]

Test unenrolling a manually enrolled host. We think you have to click minus on the user side.

Confirmed that an IT admin can remotely unenroll hosts that were manually enrolled.

[noahtalerman]

@lucasmrod @michalnicp do you know if it's possible for a device user to download/install an automatic (DEP) enrollment profile?

To do this, maybe the Fleet server can reach out to Apple with the host's serial number and get the right DEP enrollment profile back?

Context:

I'm thinking about the migration experience for hosts that were automatically enrolled (DEP).

If a device user of a DEP host is able to download a DEP profile, we might be able to make the migration experience the same for manual and DEP (a user can download/install a manual enrollment profile).

I think this is valuable because this way IT admins only need to understand, explain, and document one experience for migrating all their hosts (manual and DEP).

[noahtalerman]

Bootstrap tokens are transferred automatically TODO

It seems like Fleet will have to handle this for the IT admin.

In the following Jamf video the narrator claims "A bootstrap token does not need to be actively managed by IT admins" (8:00): https://www.youtube.com/watch?v=5zQEQwoRoDA

[noahtalerman]

FileVault escrow keys get refreshed automatically TODO

Investigating whether unenrolling a host from the old MDM solution and then reenrolling the host in the new MDM solution will refresh FileVault recovering keys.

UPDATE: It looks like this^ refresh won't happen.

For manually enrolled hosts, if FileVault was already on at the time of enrollment, we don’t see the escrow key in SimpleMDM. Two known solutions:

• Turn FileVault off by pushing a profile. This is risky.
• Script to retrieve and set the key: https://support.addigy.com/hc/en-us/articles/4925208074259-How-to-Escrow-a-FileVault-Recovery-Key-That-Didn-t-Upload-to-Addigy
  • We could do this with osquery. Set the value in Fleet DB.
  • The recovery key may be located here: /var/db/ConfigurationProfiles/fdesetup.plist

[lucasmrod]

If a device user of a DEP host is able to download a DEP profile, we might be able to make the migration experience the same for manual and DEP (a user can download/install a manual enrollment profile).

@zhumo you performed a few DEP migrations, IIRC some required device wipe but you managed to migrate a DEP device without wiping, right?

If you enroll a device manually (via following a link and installing profiles manually) then the device won't be "DEP-managed".

[michalnicp]

@lucasmrod @michalnicp do you know if it's possible for a device user to download/install an automatic (DEP) enrollment profile?

To do this, maybe the Fleet server can reach out to Apple with the host's serial number and get the right DEP enrollment profile back?

As far as I know, an MDM server can only get information about DEP enrolled devices that have already been assigned to it. It can't get any details for devices that are assigned to another MDM server.

If a device user of a DEP host is able to download a DEP profile, we might be able to make the migration experience the same for manual and DEP (a user can download/install a manual enrollment profile).

DEP profiles tell a device how to get an enrollment profile during activation (setup). How would this help with the migration experience? It's not likely that a device actually has access to the raw DEP profile.

[noahtalerman]

UPDATE: Ignore these questions. Latest questions are here: https://github.com/fleetdm/fleet/issues/8153#issuecomment-1290860681

@michalnicp when you test migration can you please help me answer the following questions:

• When you use the profile renew command, do you get the non-removable feature? Yes.
• Can Fleet, on behalf of macOS host that was added to an MDM server in Apple Business Manager, reach out to Apple to get a new DEP profile?
  • This way, the IT admin, script, or user doesn't have to run the sudo profiles renew --type enrollment command or wipe the device.

[noahtalerman]

For reference here's an outdated user journey for migration:

https://docs.google.com/drawings/d/1bUa4FQSxYm3fWg4bWvi07nfWGiHEl4BMsAKsSIOU5ww/edit

This issue's description holds the latest docs.

[noahtalerman]

@zhumo can you please review the first draft of the migration instructions (included in this issue's description) ?

[noahtalerman]

@noahtalerman ask for the script that runs the sudo profiles renew --type enrollment command. Schedule a call with Zach and Michal.

On each host, run the sudo profiles renew --type enrollment command. This command asks Apple to send the host a new DEP profile.

I think the user must be an admin user on the Mac to run the command.

If the user is a standard user, you will have to upgrade the user to admin, run the command, and then downgrade the user back to standard.

Ideally, the script just runs without user interaction. User is told to install the profile.

[noahtalerman]

@michalnicp can you please help us answer these questions?

• Can we run the profiles renew command for the admin/device user? Potentially using Fleet Desktop
• Do we need to upgrade a standard user to admin to run the command? Can the standard user accept the new profile?
• How does unenroll actually work? What MDM command is used?
• After I switch MDM servers for a host, can I still unenroll the host? We're confident the answer is yes.

[zhumo]

@noahtalerman I reviewed them in a word doc: https://docs.google.com/document/d/1Lzx35dYFWFPTUYWGWYXfvGCLHcy2QX1Uuy64izBPa78/edit?usp=sharing

[noahtalerman]

@zhumo I responded to your comments and made changes in the word doc: https://docs.google.com/document/d/1Lzx35dYFWFPTUYWGWYXfvGCLHcy2QX1Uuy64izBPa78/edit?usp=sharing

These instructions are still in "skeleton" form. This means that they include the least amount of steps/verbiage necessary (I think) and no images.

Can you please review the instructions for structure and information (are steps in the wrong order? are we missing anything?)

After this round of review, I would like to loop in Chris and Mike Thomas for help with language and images.

[michalnicp]

Can we run the profiles renew command for the admin/device user? Potentially using Fleet Desktop

Yes. We should evaluate whether there are any security concerns with orbit running the profiles command. Also, the user still needs to accept the profile in order to complete enrollment. For security reasons, I think Apple requires someone to actually click on the allow button.

According to https://macadmins.slack.com/archives/C04QVP86E/p1657180794521899?thread_ts=1657180327.201759&cid=C04QVP86E

You can not enroll in a mdm remotely. You need to have physical access to the machine to approve the profile. Apple blocks virtual clicks on the mdm enrollment profile

This is also supported by Jamf's documentation https://docs.jamf.com/10.34.0/jamf-pro/documentation/Enrollment_Methods_Using_Recon.html

macOS 11 or later does not permit the automated installation of configuration profiles using the profiles binary

Do we need to upgrade a standard user to admin to run the command? Can the standard user accept the new profile?

Standard users are not able to accept the MDM configuration profile. This is intended behaviour. According to https://macadmins.slack.com/archives/C08V5GWUC/p1634900023007900?thread_ts=1634854518.007300&cid=C08V5GWUC, someone did work around this by upgrading the user temporarily, but I am worried that this is a security concern.

In my opinion, we should not try to work around this. Instead, document that an admin user will need to log into the device to accept the profile. This is the safest approach.

How does unenroll actually work? What MDM command is used?

From "Terminating a Management Relationship" in https://developer.apple.com/business/documentation/MDM-Protocol-Reference.pdf, either remove the profile using an MDM command or return a 401 from the MDM server. micromdm seems to use the latter.

After I switch MDM servers for a host, can I still unenroll the host? We're confident the answer is yes.

Assigning a different MDM server in Apple Business manager does not unenroll the device. You can still issue MDM commands if it is still enrolled.

[zhumo]

@noahtalerman I put in some more comments.

Before gussying it up via Chris and Mike, I'd like to validate these instructions. Once you and I feel good about them, can we get eng's and Guillaume's feedback on it? Once we have alignment there, we can close this issue.

After that, once we have the full add-remove loop in dogfood, I'd like to have some of our employees use these instructions blind, esp. the upgrade on the IT admin side. Or maybe test these instructions with limited release partners. Only after that should we ask the team to gussy it up. I suspect we will make changes as we go along. This will probably all be next quarter stuff.

In the meantime, can you take screenshots from Fleet Desktop and the designs for enrollment you have and stick them in there in the appropriate places?

[noahtalerman]

Only after that should we ask the team to gussy it up. I suspect we will make changes as we go along. This will probably all be next quarter stuff.

@zhumo got it! Makes sense.

screenshots from Fleet Desktop and the designs for enrollment you have and stick them in

👍

[noahtalerman]

Yes. We should evaluate whether there are any security concerns with orbit running the profiles command.

Great.

@GuillaumeRoss we'd like Fleet Desktop to run the sudo profiles renew --type enrollment command for the user.

This way, neither the IT admin nor the device user has to run this command to request the new DEP profile from Apple.

What do you think?

[noahtalerman]

the user still needs to accept the profile in order to complete enrollment

Yep! The plan is for the My device page to walk the user through these steps: https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=10566%3A315998

@michalnicp about how long does the request to Apple take when running the sudo profiles renew --type enrollment command?

Ideally, the UI can poll this request for 5 seconds max before hearing from Apple if the device received a DEP profile or not. This way, the UI knows which set of instructions (manual or automatic) to show to the user.

[noahtalerman]

Standard users are not able to accept the MDM configuration profile. This is intended behaviour. According to https://macadmins.slack.com/archives/C08V5GWUC/p1634900023007900?thread_ts=1634854518.007300&cid=C08V5GWUC, someone did work around this by upgrading the user temporarily, but I am worried that this is a security concern.

In my opinion, we should not try to work around this. Instead, document that an admin user will need to log into the device to accept the profile. This is the safest approach.

@michalnicp a different MDM solution offers a solution for upgrading the standard user to admin and then downgrading the user.

Maybe we can add an option, that is off by default, that allows Fleet Desktop to do this.

Can you please help me understand how much effort this would take?

[michalnicp]

@michalnicp about how long does the request to Apple take when running the sudo profiles renew --type enrollment command?

It takes about 4 s to run the following command

% time sudo profiles renew --type enrollment
sudo profiles renew --type enrollment  0.01s user 0.02s system 0% cpu 4.081 total

I don't know how much of this time is spent making requests to Apple vs doing other things. Do you need to know that?

Ideally, the UI can poll this request for 5 seconds max before hearing from Apple if the device received a DEP profile or not. This way, the UI knows which set of instructions (manual or automatic) to show to the user.

I don't understand this question. The device would be making the request to Apple, not the fleet server. Also, why would we run the profiles renew --type enrollment command to determine which instructions to show?

[michalnicp]

@michalnicp a different MDM solution offers a solution for upgrading the standard user to admin and then downgrading the user.

which MDM solution is that? perhaps I can look into it further to see how they do it

[GuillaumeRoss]

From a security point of view, I don't have a major hesitation against running commands like this from Desktop, since we know the threat model will change a lot when we decide to add custom script features etc.

I am not sure how much this helps from a UX point of view though, since the user needs to be admin anyway to accept the pop-up? We'd be essentially only saving one command from being pasted, and we have not helped non-admin users at all?

[noahtalerman]

UPDATE: Standard users can navigate to System preferences > Profiles however they are asked to enter an administrator password to install the profile.

I am not sure how much this helps from a UX point of view though, since the user needs to be admin anyway to accept the pop-up?

@GuillaumeRoss interesting. Standard can't navigate to System preferences > Profiles to accept the profile?

[noahtalerman]

Noah:

Curious on how the MDM migration is going. How are you tweaking the Fleet policies?

Guillaume:

I just tweaked a policy that checked if we were on SimpleMDM and replaced it for checking if the device is on Fleet's MDM server. Also I had a policy that failed on my Mac (Secure Keyboard Entry) and I couldn’t figure out why - turns out you need to reboot for it to be applied properly.

[noahtalerman]

@zhumo I met with Michal and Guillaume to discuss Activation Lock.

We think the best path forward is to ensure that Activation Lock is prohibited by default for DEP hosts and tell IT admins to ask the device users to disable Activation Lock during migration.

This is because if Activation Lock is enabled, the IT admin will need the Activation Lock bypass code to wipe and reuse the device. This is problematic because, according to Kandji, "Activation Lock bypass codes can only be retrieved from the Mac up to 30 days after the device is supervised."

This means that the default automatic (DEP) enrollment profile in Fleet will not allow Activation Lock.

This also means that the migration docs will tell the IT admin to ask device users to disable Activation Lock. I added an "Activation Lock" section to the draft docs here: https://docs.google.com/document/d/1Lzx35dYFWFPTUYWGWYXfvGCLHcy2QX1Uuy64izBPa78/edit#heading=h.dw7gdjkxbjqq

[noahtalerman]

@zwass @michalnicp @GuillaumeRoss when you get the chance, can you please review the draft MDM migration docs? https://docs.google.com/document/d/1Lzx35dYFWFPTUYWGWYXfvGCLHcy2QX1Uuy64izBPa78/edit

Please leave feedback/questions as comments in that doc^

[zhumo]

@noahtalerman sounds good to me

[noahtalerman]

Link to notes that include a discussion about migration with a current Fleet customer (internal): https://docs.google.com/document/d/1E0VU4AcB6UTVRd4JKD45Saxh9Gz-mkO3LnGSTBDLEZo/edit

To find the section about migration search the doc above (cmd + f) for "on MDM migration".

[zhumo]

@noahtalerman C&C: Let's move this forward.

[noahtalerman]

Hey @lukeheath I moved this issue into the designed and assigned you. At some point several weeks ago, Michal, Zach, Mo and I aligned on these requirements.

Because this call was awhile ago and isn't well documented, I added an agenda item to the MDM Team weekly on Monday Dec 19 to that about this.

[noahtalerman]

@roperzh @lukeheath this is the issue that we looked at during the MDM team weekly on 2022-12-19.

When spec'ing / estimating the issue please let me know if you have any concerns with the approach we discussed:

As a recap, we'd like Fleet to download the automatic enrollment (DEP) profile for the end user if they were automatically enrolled to the old MDM solution.

This way, neither the IT admin nor the end user has to run the sudo profiles renew --type enrollment to request a new automatic enrollment profile from Apple.

We discussed Fleet running sudo profiles renew --type enrollment command for the user.

[lukeheath]

@ghernandez345 @roperzh Assigning this issue to you to break into issues and spec for estimation on Wednesday. Please follow the same process I outlined in comment here. Thank you!

Noah provided some additional notes in the comment above ^

[roperzh]

@noahtalerman while specifying this issue I realized that we can run the command for the user only if they have orbit installed in the host.

So I think that additionally, we have to document in the migration instructions that If the host doesn't have orbit, the end user or the IT admin will have to run that command manually OR install orbit manually.

Edit: I think this might also affect the copy of the modal for automatic enrollment in the UI

Does that make sense?

[noahtalerman]

we can run the command for the user only if they have orbit installed in the host.

@roperzh makes sense! In the migration docs, we tell the IT admin that adding hosts (installing orbit) is required before migrating from their old MDM.

Does this address what you brought up? If no, how should we change the docs?

EDIT: Oh, I see there's a case in which the IT admin uses plain osquery to add hosts. I think we should add a note to the docs that in order to migrate from old MDM, they must use fleetd (orbit).

I think this might also affect the copy of the modal for automatic enrollment in the UI

Are you referencing the modal that shows the end user steps to turn on MDM (screenshot below)?

If so, the end user will only see this modal if they have Fleet Desktop (and orbit I think) installed. Does this address what you brought up?

[roperzh]

@noahtalerman all of that makes sense to me, thanks for clarifying!

[noahtalerman]

@roperzh cool! As always, please let me know if you think I'm missing something. There are a lot of hidden details/complexities.

[lukeheath]

@RachelElysia Would you please create an issue for the UI portion of this story?

[mna]

@roperzh I wonder if there might be a child issue missing for this story - there's #9124 that makes orbit add the serial number in its POST to enroll the device, but I don't see a ticket that covers the API side to modify the enroll-from-orbit handler to make use of that new serial number field if present. I don't think it's a big change, so if it's easier we can make it part of the #9124 ticket (or maybe that was your goal the whole time).

[roperzh]

@mna thanks! yes my idea was to tackle both things in #9124 but it should be explicitly noted in the issue. I will update accordingly.

[lukeheath]

@noahtalerman Heads up: This story will not close this sprint. During testing, an edge case that requires addressing was discovered. We have created a new sub-task to address it in: https://github.com/fleetdm/fleet/issues/9124. @mna made good progress, but merging will require a bit more work next week. We expect to complete all sub-tasks for this story early next week.

[noahtalerman]

@lukeheath during today's standup (after your above comment), we discussed that #9124 doesn't need to be completed to call the "Migrate between MDM solutions" done.

FYI I left the same comment here in #9124: https://github.com/fleetdm/fleet/issues/9124#issuecomment-1414098474

[roperzh]

@xpkoala heads-up I moved this to "Awaiting QA".

One way to test this:

• Simulate that you have a device previously enrolled into another MDM by:
  • DEP enroll a machine to your Fleet server
  • Unenroll the host from MDM by deleting the configuration profile from System Preferences > Profiles
  • Delete the host in the Fleet UI
• Build a new fleet-osquery.pkg that contains an orbit version with the changes shipped for this issue
• Install orbit in the computer you previously DEP enrolled
• You should see a prompt to enroll to MDM, and successfully enroll

[fleet-release]

Clouds give way Smooth migration between MDMs Stress free control

[fleet-release]

Ease of transition, From one MDM to Fleet, A gentle breeze blows.