Mac set up with "Migration assistant" should not be linked to the same FleetDM host as the computer it was restored from

[valentinpezon-primo]

Fleet version: 4.47.3

---

💥  Actual behavior

A user had a host enrolled in fleet, with a remoteId 1, with the follow information :

• Serial number : serial_A (hidden for privacy)
• model identifier: MacBookPro17,1
• UUID : uuid_A ((hidden for privacy)

Few weeks later, the end-user proceeded to buy a new computer, and enroll the host on fleet aswell.

The problem is the following :

• The host with remoteId 1 was overrode : the serial number & model identifer, and all other data changed, only the UUID stayed the same

🕯️ More info

• The previous host was previously enrolled in another MDM, thanks to this we can confirm the UUID was the same for the old computer

• The current device enrolled in fleet has this information (same UUID but diff serial):

• The host has an "Added to fleet" date set at 1 month ago, but the new computer has been bought recently (10 days ago)

[primo-vincent]

We got new informations from the end user, we are able to provide steps to reproduce.

First we have the confirmation the device serial number change over the time between 2 devices on the same host :

As you can see, the serial number given 23 hours was MK***QM and today is FV***5D. 2 agents installed on 2 different devices seems to report to the same host in fleet.

How to reproduce :

• enroll mac 1
• take another mac 2, wipe it and use the tranfer assistant from mac 1

We should never have 2 agents on 2 different devices reporting on the same host : What happen if I wipe the wrong device ? What happen if I lock the wrong device ? How can I ensure to run WIPE command on the first device only and the LOCK command on the second if both are currently offline ?

[nonpunctual]

@ksatter & I discussed. She believes the node ID is being carried over by macOS Migration Assistant, so, even though the new Host (the computer to which the data from the already enrolled Host is migrated) has a different serial number & Hardware UUID (It may or may not have the same host name I suppose depending on the org's conventions...) Fleet is seeing the new Host as the previously enrolled Host.

Can a new node ID be issued dynamically to a previously enrolled host? If the node ID is the "primary key" for the record is it possible in this state to shuttle the data to a new device record?

This enrollment scenario is an edge case that could be prevented by instructing admins to remove Fleet prior to using Migration Assistant. Another thought I had is I wonder if there is a way to build the Fleet Desktop app so that it is not carried over by Migration Assistant, i.e., maybe there are Apple frameworks / APIs for this, but, I don't know if that's a thing.

[georgekarrv]

https://fleetdm.slack.com/archives/C061ZA91Y1J/p1711728725996399?thread_ts=1711644761.648489&cid=C061ZA91Y1J Discussion on slack with more context

[georgekarrv]

MDM team will take a look at this asap

[nonpunctual]

Since we didn't have the typical template for this (cutomer created issue) I think 2 possible solutions are:

• Have Fleet identify / create a new Host record if it sees a node key it's seen before that has a different hardware UUID
• Somehow modify the Fleet Desktop app so that it does not get carried over by Migration Assistant (I don't even know if that's possible.)

[ksatter]

@georgekarrv Is there any additional info we could gather that would be helpful on this ticket?

[pintomi1989]

Notes from session today:

customer-preston has already had at least 10 reports of migration assistance issues

If someone is getting a new Mac, puts old device in inventory, then re-assigns to intern for example:

• They use migration assistant (Includes Fleet agent in migration with all of their other data etc)
• They end up with two devices linked to the same Fleet ID
• This could result in data loss if a wipe command was ran on one device and mistakenly impacted another device

@nonpunctual : Fleet identifier is what’s being copied, not a hardware UUID

• It’s the primary key for the record in Fleet is being duplicated → Not enrolling as new device
• Migration assistant is not used with enterprise workflows, many orgs block it

@nonpunctual - If blocking this is an option would that work?

• You can blocklist a process in other MDM tools
• We could theoretically duplicate this → Create a launch agent that waits for the process and kill it when we see it
• This is pre-enrollment on a new machine → Would have to kill it on the old machine

@noahtalerman - We should understand how it works, would be nice to take that path

[noahtalerman]

How to reproduce :

• enroll mac 1
• take another mac 2, wipe it and use the transfer assistant from mac 1

Hey @valentinpezon-primo!

After using the transfer/migration assistant, do you know if mac 2 has MDM turned on (aka enrolled).

Does mac 2 get MDM profiles and commands without the end user doing anything else?

Or, does the end user have to install the enrollment profile on mac 2? After using the transfer/migration assistant.

[nonpunctual]

There is an option in Migration Assistant to transfer settings. If the end user is doing this on their own I would expect that they would sometimes see profiles & sometimes not & often Migration Assistant does not correctly handle MDM profiles.

Example from customer yesterday:

[noahtalerman]

UPDATE: Please ignore my comment! I found the Slack thread from customer-ufa

Hey @ksatter, does customer-ufa use migration assistant on their Macs?

What role at the customer's org does this and for what workflow? Please add as many details as possible. Thanks!

As a guess, help desk might instruct end user's to use migration assistant when the end user gets a new, upgraded mac.

[noahtalerman]

• When using Apple's Migration Assistant, we want the new Mac and the old Mac to appear as unique host's in Fleet
• Research: If the old Mac is enrolled to Fleet w/ MDM turned on, what happens to MDM profiles?

Hey @georgekarrv I updated the "To fix" section (see above), passed this issue back to you, and added it to the release board.

[nonpunctual]

Gave customer-preston the following workaround for blocking the Migration Assistant.app process:

Below is a script that will write out a script + launch daemon to block Migration Assistant. Not saying you should use it :slightly_smiling_face: just wanted you to have it in case you wish to try it. Also included a video showing the block. To use, you just need to execute the script on a Host. To remove, just delete the Launch Daemon & script files from their paths & run sudo launchctl bootout system /Library/LaunchDaemons/com.primo.block.migration.assistant.plist

#!/bin/sh


# write out blocking script
/bin/cat << 'EOF' > /opt/orbit/bin/blk.migr.asst.sh
#!/bin/sh

if /usr/bin/pgrep -ail 'Migration Assistant'
then
    /usr/bin/osascript -e "display dialog \"Migration Assistant is blocked on this computer. Please contact your administrator for help.\" buttons {\"OK\"} default button 1 with title \"Migration Assistant Blocked\" with icon file \"System:Library:CoreServices:CoreTypes.bundle:Contents:Resources:AlertStopIcon.icns\""
    /usr/bin/pkill -ail 'Migration Assistant'
fi
EOF
/bin/chmod 755 /opt/orbit/bin/blk.migr.asst.sh
/usr/sbin/chown 0:0 /opt/orbit/bin/blk.migr.asst.sh


# write out launch daemon
/bin/cat << 'EOF' > /Library/LaunchDaemons/com.blah.block.migration.assistant.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.blah.block.migration.assistant</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/sh</string>
        <string>/opt/orbit/bin/blk.migr.asst.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>
EOF
/bin/chmod 644 /Library/LaunchDaemons/com.blah.block.migration.assistant.plist
/usr/sbin/chown 0:0 /Library/LaunchDaemons/com.blah.block.migration.assistant.plist
/usr/bin/plutil -convert binary1 /Library/LaunchDaemons/com.blah.block.migration.assistant.plist

# start launch daemon
/bin/launchctl bootstrap system /Library/LaunchDaemons/com.blah.block.migration.assistant.plist

[zayhanlon]

@georgekarrv Do we think we'll get this into 4.51.1? Thanks!

[georgekarrv]

We can prioritize working on this one first this sprint. It's still possible upon development it takes longer so I cannot guarantee it at this point

[jahzielv]

Hi team! While trying to create a fix for this, we found that the root cause is this known osquery issue. We've found a workaround that should solve this problem without needing to change osquery though; a PR should be coming soon!

[jahzielv]

TL;DR for the PR:

We added an additional call out to osquery to pull the hardware UUID, but we are passing osquery a random path (not the one that's in the Orbit root directory) to guarantee that we pull the latest, non-cached hardware UUID. If the latest and the cached values do not match, then we know we're on a new machine, so we delete the relevant files in the Orbit root directory and restart Orbit, which will enroll the new machine as a new host in Fleet.

[georgekarrv]

Verified enrolled as new device

[fleet-release]

Migration Assistant's flow, Old and new Macs both show. Fleet's embrace grows.