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.plistThe 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"
