Home > Active Directory, Mac administration, macOS, Scripting > Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. In my testing in 2016, everything seemed to work right and I didn’t see any problems with it on OS X El Capitan.

Fast forward a couple of years and a colleague of mine, Per Oloffson, began running into a weird problem with upgrading Macs from Sierra to High Sierra. When he upgraded Macs from macOS Sierra to macOS High Sierra, he was finding that Macs that had been migrated from AD mobile accounts to local accounts were having those same accounts break.

After a considerable amount of troubleshooting, he was able to narrow it down to the macOS High Sierra installer changing the password hash on those accounts. But why was it changing them?

In short, it was changing them because of a bug in my original MigrateADMobileAccounttoLocalAccount.command interactive migration script. Sorry, Per. For more details, please see below the jump.

The problematic sections are highlighted below. When the script backed up the AD mobile account’s password and then restored it, it was adding single quotes to the beginning and end of the password hash string.

Screen Shot 2018 06 15 at 7 32 06 PM

The password hash string should have looked like this:

Screenshot 2018 06 15 13 31 17

Instead, it looked like this:

Screenshot 2018 06 15 13 31 18

The odd part of the situation is that macOS Sierra was seemingly OK with the extra characters in the password string. It wasn’t until the macOS High Sierra installer re-checked and altered the account plist that the problem occurred.

To fix the migration process, I’ve updated the script to better handle the account password backup and restoration process. The backup process is now querying dscl for the correct XML output and restoring it, which should address the problem with the script.

Screen Shot 2018 06 15 at 7 55 24 PM

In my testing, the password hash is now appearing correctly in the account’s plist file.

Screen Shot 2018 06 15 at 8 23 03 PM

Testing

This script has been tested and verified to migrate AD mobile accounts to local accounts on the following versions of macOS:

  • macOS 10.13.5

In that testing, I did the following:

Testing on logged-in AD mobile user account:

  1. I set up an AD-bound VM and created an AD mobile account with admin privileges.
  2. I logged into the AD mobile account and ran the script while logged in as that account.
  3. Once the account had been migrated, I rebooted and verified that I could log in at the OS login window.
  4. I changed the password for the local account to a new one and rebooted.
  5. I verified that I could log in at the OS login window with the new password.

Testing on logged-out AD mobile user account:

  1. I set up an AD-bound VM and created an AD mobile account with admin privileges.
  2. I logged into the VM using a local account which was not the AD mobile account and ran the script while logged in as that account.
  3. Once the account had been migrated, I logged out and verified that I could log in at the OS login window with the just-migrated account.
  4. I changed the password for the newly-migrated local account to a new one and rebooted.
  5. I verified that I could log in at the OS login window with the new password.

Note: I did not test with FileVault-enabled accounts.

Advisory: Older versions of OS X and macOS were not tested and I have no idea if the script will work on those older OS versions.

Warning: I was able to test in my shop’s AD environment and verified that everything worked. That does not guarantee it will work in your environment. Test thoroughly before deploying in your own AD environment.

The updated script is available below, and also available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/migrate_ad_mobile_account_to_local_account

  1. Matt
    June 18, 2018 at 6:59 pm

    Is there a way to fix this issue on an affected machine post migration?

  2. June 18, 2018 at 8:33 pm

    because a new user is being created, I assume an assigned secureToken is lost in the process? Is there anyway to transfer that as part of the process? Otherwise FV2 users will lose Decryption capabilities.

    • June 18, 2018 at 8:47 pm

      Oh, I see… the AuthenticationAuthority Key contains the “;SecureToken;”. So when you delete the key, you lose the token.

      Still this now renders FV2 user incapable of decryption in 10.13.

      • June 18, 2018 at 10:59 pm

        So I’ve solved my issue… I am not sure why this works, and every ounce of me tells me that it shouldn’t. But I’ve tested and retested 10 times and it works every time.

        I added:

        /usr/bin/dscl . -create /users/$netname AuthenticationAuthority SecureToken

        Below:

        /usr/bin/dscl . -create /users/$netname AuthenticationAuthority “${shadowhash}”

        And now FV2 is not broken for me in 10.13 when I run the script. I can reboot and login to FV2 immediately after running it. I verified that the account is fully migrated from mobile to local as well.

      • June 18, 2018 at 11:30 pm

        Ok so some weirdness… it does not have to be SecureToken, any string will work. I just tried it with TEST…

        I also just realized that at some point in me messing with it I rolled back to the previous:

        shadowhash=$(/usr/bin/dscl . -read /Users/$user AuthenticationAuthority | grep ” ;ShadowHash;HASHLIST:<")

        and

        /usr/bin/dscl . -create /users/$user AuthenticationAuthority \'$shadowhash\'

        So what I am assuming is happening is that $shadowhash is also grabbing ;SecureToken; as well as the password hash. An echo of $shadowhash shows as much.

        For whatever reason however, that doesn't leave me at a status where I can authenticate to FV2 in 10.13.5 on reboot. But if I append a:

        /usr/bin/dscl . -create /users/$netname AuthenticationAuthority AnyString

        afterwards… I can. I have no idea WHY this is working for me… but it is.

  3. lisacherie
    June 20, 2018 at 4:12 pm

    Using the original perl version of the script with 10.13.4, in very minimal testing, does not appear to have problems unlocking file vault, logging in, or changing passwords (and then unlocking FV after the password change) following an account conversion. More extensive testing is required to investigate what Rich has found for the original perl version.
    Note the perl version is using a string within a string for the “system” function to execute the dscl command rather than as a command in bash.

  4. Matt
    July 9, 2018 at 8:55 pm

    In using your updated script, we have seen a few cases where the user is no longer able to log in. This is without a High Sierra Upgrade. When I attempt to reset their password from the command line I get the following:
    DS Error: -14165 (eDSAuthPasswordQualityCheckFailed)

    I have tried a few different passwords as well as verified that the machine is unbound and is now a local account.

    Any insight on a resolution?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: