Home > Active Directory, Mac OS X, macOS, Scripting > Migrating AD mobile accounts to local user accounts

Migrating AD mobile accounts to local user accounts

One of the practices that has historically helped Macs fit better into enterprise environments has been to bind Macs to Active Directory (AD) domains and use AD mobile accounts, using either Apple’s own AD directory service plug-in or a third-party product like Centrify. However, this practice has meant that the password for the mobile account is being controlled by a service located outside of the AD-bound Mac. This has led to problems in the following areas:

With the recent availability of tools like Apple’s Enterprise Connect and NoMAD, it’s now possible to provide the advantages of being connected to Active Directory to your Mac without actually having to bind your Mac to an AD domain. This has led to more environments not binding their Macs to AD and using either Enterprise Connect or NoMAD with local accounts.

With local accounts, all password management is done on the individual Mac. This means that problems with keychain and FileVault password synchronization are vastly reduced because the password change mechanism for a local account includes updating both the keychain and FileVault 2 automatically with the new authentication credentials.

For those shops that have been binding their Macs and using mobile accounts, but want to switch to the new local accounts + Enterprise Connect / NoMAD model, there is an account-related challenge to overcome:

How to transition from an AD mobile account, where the password is managed by AD, to a local account, where the password is managed by the individual Mac, with the least amount of disruption for your users?

To assist with this process, I’ve developed a script that can take an existing AD mobile account and migrate it to being a local account with the same username, password, UID, and GID. For more details, see below the jump.

The script I’ve developed is interactive and designed to convert an existing Active Directory mobile account to a local account. Because the existing account is being modified, instead of being deleted and replaced with a new local account, the following account characteristics do not change:

This provides the following advantages:

  • The home folder does not need to be renamed
  • Existing keychains and FileVault enablement continue to work
  • Any applications, files and directories where the AD mobile account had access rights, the new local account will have those same access rights.

The script must be run with root privileges and uses the following process:

1. Detect if the Mac is bound to AD and offer to unbind the Mac from AD if desired
2. Display a list of the accounts with a UID greater than 1000
3. Once an account is selected, back up the password hash of the account from the AuthenticationAuthority attribute
4. Remove the following attributes from the specified account:

5. Recreate the AuthenticationAuthority attribute and restore the password hash of the account from backup
6. Restart the directory services process
7. Check to see if the conversion process succeeded by checking the AuthenticationAuthority attribute for the value Active Directory.
8. If the conversion process succeeded, update the permissions on the account’s home folder.
9. Prompt if admin rights should be granted for the specified account


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

  • OS X 10.11.6
  • macOS 10.12.2

In that testing, I did the following:

  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.

It has also been tested with FileVault 2-enabled accounts on both OS X 10.11.6 and macOS 10.11.2. In that testing, I did the following:

  1. Encrypt an AD-bound VM with an AD mobile account
  2. Once encryption had finished, I logged into the AD mobile account and ran the migration 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 FileVault login screen with the current password.
  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 FileVault login screen with the new password.

Note: It is not necessary to be logged in as the account being migrated. I also verified that I could migrate a standard mobile account without admin privileges by logging into a separate account with admin privileges, running the script and selecting the standard mobile account from the list.

Advisory: Older versions of OS X 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 script is available below:

The script is also available on Github at the following address:


Hat tip to Pat Gallagher and Lisa Davies. I modeled the script’s functionality off of Pat’s MigrateUserHomeToDomainAcct.sh script (designed to move local accounts to network accounts) and Lisa’s Perl script to migrate AD mobile accounts to local accounts provided both inspiration and guidance for writing this one.

  1. December 21, 2016 at 9:22 pm

    Verified that this also appears to work happily under 10.10.5.

  2. April 22, 2017 at 5:06 am

    Going to sound odd but anyway to automate this script at all? We’re loving this script but would like to see if its possible to run this in some sort of automated fashion for our users.

    • May 12, 2017 at 5:51 pm

      I am trying to automate as well Daniel Ross. Though manual process works great, would be nice to deploy and run without user interaction.

  3. September 19, 2017 at 5:09 pm

    This worked phenomenally for me on 10.12.6.

    Thank you.

  4. Jimmy_T
    October 15, 2017 at 10:30 am

    Upgraded to High Sierra and found myself locked out. No possibility of accessing domain to log back in.

    Thank you for providing this very handy script!

  5. Brian Marston
    October 16, 2017 at 5:20 pm

    It worked for me on 10.13 (High Sierra). Thank you!

  6. Dave Burlington
    October 22, 2017 at 9:05 am

    Absolutely brilliant. Worked like a charm with 2017 MB Pro with High Sierra. Finally get my Touch Id Preference pane back. My AD was a legacy from a few jobs ago and has just been migrated the entire time from machine to machine. Thanks!. I assume the unusually high UID isn’t an issue

  7. Neal
    March 13, 2018 at 8:24 pm

    Hi, newbie OSX here – copying and pasting the script into script editor fails compiling due to the smart quotes everywhere. How can i compile this so it works ok – I get the syntax error: Expected end of line but found unknown token issue. Sorry 😦

  8. squishedsquirrel
    March 28, 2018 at 11:11 pm

    Possibly an isolated issue, but I did encounter one problem using it on 10.11.6. The script worked perfectly and I could log back in without issue. However, after upgrading to 10.13.3, the computer would no longer accept my login creds that worked prior to the upgrade. To fix I logged into an admin account that was never an AD account and reset my password. After that, I logged in successfully, and had no complaints from either the Keychain or Enterprise Connect.

    Thanks for the script. It is a huge time saver.

    If I were going to suggest any improvements, I would put in a chflags -R nouchg before the chown just so the chown doesn’t spit out errors on locked files.

    • squishedsquirrel
      April 6, 2018 at 2:45 pm

      Just a followup, this has happened on all machines that were migrated using the script, and then upgraded to High Sierra. Not a big deal if you have an alternate account to log in as to fix the former mobile account password, or if you boot into single user to fix the password.

  9. Mario
    April 4, 2018 at 3:32 pm

    How do I actually run this? I tried from the command line and from Finder > right-click > Open, and I just get an error.

  10. Steve
    April 13, 2018 at 4:22 am

    @Mario I converted the .sh to a .command. You’ll probably experience some permission issues running this as an executable. To ensure you have permission to run this simply head to terminal and type chmod u+x /path/to/file.command

    You should be able to run this as a executable

    • Mario
      April 17, 2018 at 8:58 pm

      Hi Steve, I applied the chmod to the file, then tried running it, and now I get the following:
      ./MigrateADMobileAccounttoLocalAccount.command: line 7: syntax error near unexpected token `newline’
      ./MigrateADMobileAccounttoLocalAccount.command: line 7: `’

      • Mario
        April 19, 2018 at 3:58 pm

        Hi Steve, Never mind. I figured it out. When I clicked the link to download from Github, it downloaded the webpage instead of the script. I just grabbed the contents of your script above and pasted it into a new plain text file. I named it what you named it, and ran it on a test computer. Worked like a charm. Thank you VERY VERY much. This will save us so much time.

  11. Scott
    April 19, 2018 at 5:04 pm

    What positive/negative does this script bring, compared to just unbinding the workstation from AD?

    Doesn’t unbinding makes the AD mobile account on the computer a local account?

    • April 19, 2018 at 5:15 pm

      No, It remains a mobile account but now it can’t communicate with AD. Since it can’t communicate with AD, it’s now not possible to change the password to the now-orphaned mobile account.

      • Scott
        April 19, 2018 at 5:28 pm

        So Enterprise Connect wouldn’t be able to change the password either of the orphaned mobile account?

  12. Julia
    April 27, 2018 at 11:04 pm

    this worked like a charm for me on 10.13.4
    Thanks so much, I spent a bunch of time yesterday when moving a backup from a (former) work computer to a personal on, tried to do this manually and screwed myself up somewhere in the process. had to restore again from backup, then stumbled over your scirpt and solved the whole thing in two minutes. awesome stuff, thanks again!

  13. Michael Litton
    May 15, 2018 at 1:56 pm

    Has anyone automated this? I was thinking I could replace parts with IF/THEN since my answer to all would be ‘yes’.

  14. Neil Reicher
    May 22, 2018 at 12:39 am

    Should I be worried about how this will affect users of multiple computers, say a single user with a laptop and a desktop? Or will it just work to make the local accounts on the respective machines? Thanks

  15. Mike
    June 20, 2018 at 7:07 pm

    Hi there – I have Open Directory (from MacOS Server, which I no longer wish to use) Mobile accounts which I would like to convert to local accounts. I have tried this script but it gives the error message that the respective accounts are not AD mobile accounts. Any ideas? Thanks

  16. Hugo
    July 10, 2018 at 10:53 pm

    Hi There:

    I´ve been trying to run this script but I keep getting this error message:

    /Users/gadmin/Documents/MigrateADMobileAccounttoLocalAccount.command: line 1: {rtf1ansiansicpg1252cocoartf1504cocoasubrtf830: command not found
    /Users/gadmin/Documents/MigrateADMobileAccounttoLocalAccount.command: line 2: syntax error near unexpected token `}’
    /Users/gadmin/Documents/MigrateADMobileAccounttoLocalAccount.command: line 2: `{\fonttbl\f0\fnil\fcharset0 Menlo-Regular;}’
    Saving session…
    …copying shared history…
    …saving history…truncating history files…

    [Process completed]

    It doesn´t do anything else.

    The way I am running it is:

    Copying the script in a plain text
    Saving the file with the name MigrateADMobileAccounttoLocalAccount.command
    Run the file in a Command Line

    Thanks in advance for any tips.


  17. Rob
    August 10, 2018 at 1:17 pm

    how would I run this script without prompts for any AD mobile account found on the system?

  18. Michel Donais
    August 27, 2018 at 7:34 pm

    For people who asks questions on the script, I was in a situation where I used to have an old Open Directory on my server (Mac Mini), created my user account with it on my main laptop, but then, eventually, Apple decided to pretty much remove the kludge that was Open Directory. It wasn’t working that well to be honest. So I was stuck with an “Admin, Mobile” account without any external Directory service. My account was half-way converted throughout the years too, so my account was defined as ” ;LocalCachedUser;/LDAPv3…” with an OriginalAuthenticationAuthority of ” ;ApplePasswordServer;0x01….” .

    The script, as shown, thought my account was not an AD account. It kind of wasn’t, but it wasn’t a shadowhash either. I modified the script by removing the if / else that checks whether the account is an AD account. I left the Mobile check. Once I ran the script, it worked well!

    YMMV and you might end up borking your usual accounts, as a failsafe is not there anymore.

  19. Neil Reicher
    November 28, 2018 at 2:31 am

    Would love to see this working on Mojave.
    My AD users aren’t being detected as AD and when I finish the unbind, it offers me an empty list of eligible users to convert.
    Tried while logged in as that user; and while logged in as a local admin… same results however. 😦

    • Chris
      March 20, 2019 at 7:19 pm

      I was able to get it to work on Mojave. Signed in as local admin user on the machine and converted one mobile account to local account.

  20. Abraham
    April 19, 2019 at 2:37 pm

    Anyone else having an issue where the dscl delete command doesn’t work in the script, but does work when ran in a terminal window?

  21. June 10, 2019 at 5:37 pm

    Solved issue where used Migration Assistant to migrate mobile acct from loaner 10.14 to new 10.14 mac. On new mac, user could not login until new mac was removed from AD, and then the temp password assigned by MigAsst worked. But since was still an orphaned mobile acct, user could not change password. After running script to convert to local account, then user could change password.

  22. Christian
    July 23, 2019 at 12:45 pm

    How does this script compare to just using NoMAD Login to convert the user account from mobile to local?

  23. Mateo
    August 12, 2019 at 1:40 pm

    how does this script work when the user name changes? we are moving from username@domain.com to email.address@domain.com

  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 )

Connecting to %s

%d bloggers like this: