This helps CIO/CTOs not get all wide-eyed and sweaty when they hear just "local accounts"
#Sierra migration assistant windows 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. In fact enjoy the decrease in calls to unlock the Date/Time prefpane or network prefpane!īut 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.
#Sierra migration assistant windows full
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. 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. 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! 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Ĭp /var/db/dslocal/nodes/Default/users/$') Drag Terminal.app into the pane (or click + and select /Applications/Utilities/Terminal.app)Ĭopy the user record from the source to the targetĢ.
Select "Full Disk Access", unlock the Preference paneģ. Make sure root can get where it needs to in Terminal (otherwise you get "Operation not permitted"ġ. 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! however more testing is needed since on T2 enabled machines this mangled password could still be passed to SecureEnclave regardless of FileVault status. So it seems as a workaround #1 Migration Assistant should be run PRIOR to FileVault Encryption. 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 ) 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 -user -oldPassphrase -newPassphrase (I have yet to test this with non-Mobile accounts. 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'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.
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. Yeah, I just did this on a 10.14.3 Mac, using a TimeMachine backup of a mobile account, it's totally reproducible. Is anyone else seeing this in their environment? Have you found a way to address it aside from having users enter their own passwords (which is not great when sometimes users are not present during their workstation refresh)? Have you ditched Migration Assistant altogether and adopted a different solution for migrating user data between legacy and new Macs (strongly considering this option)? We are managing Secure Tokens for FileVault in High Sierra for all of our mobile accounts without any issues, but I am assuming that changes to FileVault in High Sierra are to blame for this bizarre step in the Migration Assistant workflow. You can enter any password in this field - although I don't recommend that! If you have the relevant user type their password in everything is fine, but if you enter anything else, it sets the user's password in the FileVault reboot to whatever you typed in, but then that is out of sync with their login password so then the machine drops them at the login window to enter their current network credentials. We have mobile AD accounts on our FileVault encrypted Macs running High Sierra and when using Migration Assistant during workstation refreshes we get a prompt that states "A password must be established for each Admin account that you wish to migrate." It then asks us to enter a password for each user that we are transferring.
0 kommentar(er)
