High Sierra Migration Assistant Password Prompts

I have a similar issue... not sure why Apple decided to break Migration Assistant... we've got AD mobile user accounts and Migration Assistant used to be able to handle these without issue. Now it seems that Migration Assistant want to give a temporary password for the mobile accounts but then we are unable to change the temporary password back to their AD password. We use the Users and Group preferences and it says that the temporary password is invalid.

Have you heard any more about this issue?

I'm seeing a similar issue with the Migration Assistant (closer to BPHelpDesk's issue), but we are not using FileVault. For us, even if the user enters their existing password when prompted during the migration, it will not accept that password when they attempt to login when the migration completes.

Have either of you found any fixes or workarounds for this issue?

Wow, this was posted almost a year ago and not solved? I am running into this same issue. I am waiting on a call back from Apple Enterprise support to see if they can give me an answer. It makes no sense why the Migration assistant would assign a temporary password to an AD account. Just stupid.

@rsahadi Does the problem still exist if both Macs are on 10.14.3?

Just curious... I’m sure that’s what Apple will tell users, lol

@sshort I am on 10.14.2 on the receiving Mac computer. There is no 10.14.3 update available from the Mac App Store.

Wow. Yeah, I just did this on a 10.14.3 Mac, using a TimeMachine backup of a mobile account, it's totally reproducible.
It's like they aren't detecting if the account is Mobile or not and just doing the same thing as it was a local account.

I've also noticed that this can be corrected (in my environment at least) by simply logging in with the users' AD password on a properly bound Mac.
The other issue though is that despite login correcting the password, it does not correct the POA (Power on Authorization) password, the temporary password does not work either (?!)
(I have yet to test this with non-Mobile accounts... more testing definitely in order...)

The bigger issue then is that if Migration Assistant is setting the user password in FileVault (or SecureEnclave on T2 machines?) which is neither the AD password nor the temporary password then you can't ever fix the password issue using:

diskutil apfs changeCryptoUserPassphrase <apfsVolumeDisk> -user <cryptoUserUUID> -oldPassphrase <oldPassphrase> -newPassphrase <newPassphrase>

The above always works like a charm - but only when the OLD password is known - in the case of "Migration Assistant password mangling of Mobile Accounts" it is not (howdya like the bug feature name ;)

So it seems as a workaround #1 Migration Assistant should be run PRIOR to FileVault Encryption... however more testing is needed since on T2 enabled machines this mangled password could still be passed to SecureEnclave regardless of FileVault status.

OK - but let's say you've migrated a Mobile Account, the password is mangled, the temporary password is not working and you just need this @$!* to work right now!

Make sure root can get where it needs to in Terminal (otherwise you get "Operation not permitted"
1. Open System Preferences... -> Security & Privacy -> Privacy tab
2. Select "Full Disk Access", unlock the Preference pane
3. Drag Terminal.app into the pane (or click + and select /Applications/Utilities/Terminal.app)
4. Quit Terminal when prompted

Copy the user record from the source to the target
1. Open Terminal
2. Make a backup copy of the mangled user record for posterity, copy in the new one, then copy and convert to ASCII for analysis:

#fill these in with correct values
userToMigrate="user"
sourceVolume="/Volume/Macintosh HD 1"
#back it up to look at later
cp /var/db/dslocal/nodes/Default/users/${userToMigrate}.plist /Users/Shared/${userToMigrate}-migrated.plist
#copy the working user record from the source Mac to the current Mac
cp "${sourceVolume}"/var/db/dslocal/nodes/Default/users/${userToMigrate}.plist /var/db/dslocal/nodes/Default/users/${userToMigrate}.plist
#if you copy the plists and convert to ASCII you can better see the differences:
cp "${sourceVolume}"/var/db/dslocal/nodes/Default/users/${userToMigrate}.plist /Users/Shared/${userToMigrate}-original.plist
plutil -convert xml1 /Users/Shared/${userToMigrate}-migrated.plist
plutil -convert xml1 /Users/Shared/${userToMigrate}-original.plist

The user should be able to login at the login window now... if not reboot, but Directory Services should pick up the change right away

For extra credit fire up FileMerge and behold the mangling...

Note: Since the hash even changes once corrected post-login (yet is is still the same password) I just wonder if Apple started using a new one way hashing methods and wanted to ensure all account passwords are updated with this method?
There had to be some motivation to introduce this temp password thing, but apparently not enough oversight to test workflows that use Mobile accounts!

As a small follow-up...
When the Mobile Users is restored if you are offline/off-domain when you login it will use the temp password (and ask you to reset your Keychain password to that temp password), once you connect to the domain if you go back to the the login window it should accept you AD password if properly bound. I am still not sure why the temp password was not working nor the AD password when I was on the domain in earlier tests but I can't recreate it anymore.

In the latest test I restored an AD user while on-domain, taking a temp password
At login I unplugged the network adapter and the temp password was used
Rebooted and FV POA also took the temp password
On 2nd reboot, plugged in, FV POA took temp password, but stopped at login window wanting the AD password, it was accepted
3rd reboot, the temp password was still being used by FileVault
4th reboot, giving it a chance to Do the Right Thing™ it doesn't, still the temp password
Remediation is to run:

diskutil apfs changeCryptoUserPassphrase <apfsVolumeDisk> -user <cryptoUserUUID> -oldPassphrase <oldPassphrase> -newPassphrase <newPassphrase>

And because there might be a lot of 'hacky' ways to get the UUID of the console user, I'll save everyone the time with this:

#GID of console user
cryptoUserUUID=$(dscl . read /Users/$(stat -f %Su /dev/console) GeneratedUID | awk -F': ' '{print $2}')

It's still slightly hacky using awk instead of outputting dscl in plist format and using PlistBuddy but simplicity and readability counts in my book too!

It seems the better 'fail-safe' method to ensuring the password is the same with no shenanigans is to simply click the Promote to Admin button, then you may specify the password to be used and ensure it is the same as the AD password.

I know, elevating an end-user to an admin is not the first thought of some admins, it wasn't mine, hence all the damn testing! But with SIP and other TCC/PPPC controls out there (to even preemptively Deny Terminal Full Disk access if necessary) you can let your users be admin and not worry as much since root loses access to mess with /Users and /var/db/ in addition to SIP's protections. In fact enjoy the decrease in calls to unlock the Date/Time prefpane or network prefpane!

But still it's ridiculous this tools lets to you change passwords on a Mobile Account which then affects the FileVault password so that it never syncs to the AD password. I think the writing is on the wall for Mobile Account support! Jamf Connect Login with Azure sure makes no mention of Mobile Accounts, it's local or as Apple has reminded us to say "Local Managed Accounts" or similar since MDM can manage password age and complexity rules. This helps CIO/CTOs not get all wide-eyed and sweaty when they hear just "local accounts"

Sorry to keep bumping this thread but I've noticed more freaky behavior on migrated accounts on 10.14.3
When off-domain, a migrated Mobile account will revert to the temporary/set password!
Once back on-domain it will auth to the domain password.

So this means if you reboot off-domain if you went to the trouble of syncing your FileVault password, it will still work BUT you will be stopped at loginwindow where you'll need to remember the temp/set password. Also Keychain will then want to change your password back to the temp password or delete the keychain (I thought it was nice they got rid of the user "confusing" 3rd choice, in this case I miss it!).

There was a thread in JamfNation, I can't find the link, where someone said this was fixed in the latest betas... I have yet to confirm that but in the meantime...
Until that gets fixed, it might be a good idea to place Migration Assistant under Restricted Software: Block Migration Assistant
If they do fix it in 10.14.14, you could use an exclusion group to block everyone OSes where it's broken