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:


cached_groups
cached_auth_policy
CopyTimestamp – This attribute is used by the OS to determine if the account is a mobile account
SMBPrimaryGroupSID
OriginalAuthenticationAuthority
OriginalNodeName
AuthenticationAuthority
SMBSID
SMBScriptPath
SMBPasswordLastSet
SMBGroupRID
PrimaryNTDomain
AppleMetaRecordName
MCXSettings
MCXFlags

view raw

gistfile1.txt

hosted with ❤ by GitHub

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

Testing

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:


#!/bin/bash
# Modified 4/5/2019
Version=1.4
# Original source is from MigrateUserHomeToDomainAcct.sh
# Written by Patrick Gallagher – https://twitter.com/patgmac
#
# Guidance and inspiration from Lisa Davies:
# http://lisacherie.com/?p=239
#
# Modified by Rich Trouton
#
# Version 1.0 – Migrates an Active Directory mobile account to a local account by 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. Remove the following attributes from the specified account:
#
# cached_groups
# cached_auth_policy
# CopyTimestamp – This attribute is used by the OS to determine if the account is a mobile account
# SMBPrimaryGroupSID
# OriginalAuthenticationAuthority
# OriginalNodeName
# SMBSID
# SMBScriptPath
# SMBPasswordLastSet
# SMBGroupRID
# PrimaryNTDomain
# AppleMetaRecordName
# MCXSettings
# MCXFlags
#
# 4. Selectively modify the account's AuthenticationAuthority attribute to remove AD-specific attributes.
# 5. Restart the directory services process
# 6. Check to see if the conversion process succeeded by checking the OriginalNodeName attribute for the value "Active Directory"
# 7. If the conversion process succeeded, update the permissions on the account's home folder.
# 8. Prompt if admin rights should be granted for the specified account
#
# Version 1.1
#
# Changes:
#
# 1. After conversion, the specified account is added to the staff group. All local accounts on this Mac are members of the staff group,
# but AD mobile accounts are not members of the staff group.
# 2. The "accounttype" variable is now checking the AuthenticationAuthority attribute instead of the OriginalNodeName attribute.
# The reason for Change 2's attributes change is that the AuthenticationAuthority attribute will exist following the conversion
# process while the OriginalNodeName attribute may not.
#
#
# Version 1.2
#
# Changes:
#
# Add RemoveAD function to handle the following tasks:
#
# 1. Force unbind the Mac from Active Directory
# 2. Deletes the Active Directory domain from the custom /Search and /Search/Contacts paths
# 3. Changes the /Search and /Search/Contacts path type from Custom to Automatic
#
# Thanks to Rick Lemmon for the suggested changes to the AD unbind process.
#
# Version 1.3
#
# Changes:
#
# Fix to account password backup and restore process. Previous versions
# of the script were adding extra quote marks to the account's plist
# file located in /var/db/dslocal/nodes/Default/users/.
#
# Version 1.4
#
# Changes:
#
# macOS 10.14.4 will remove the the actual ShadowHashData key immediately
# if the AuthenticationAuthority array value which references the ShadowHash
# is removed from the AuthenticationAuthority array. To address this, the
# existing AuthenticationAuthority array will be modified to remove the Kerberos
# and LocalCachedUser user values.
#
# Thanks to the anonymous reporter who provided the bug report and fix.
clear
listUsers="$(/usr/bin/dscl . list /Users UniqueID | awk '$2 > 1000 {print $1}') FINISHED"
FullScriptName=`basename "$0"`
ShowVersion="$FullScriptName $Version"
check4AD=`/usr/bin/dscl localhost -list . | grep "Active Directory"`
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
/bin/echo "********* Running $FullScriptName Version $Version *********"
RunAsRoot()
{
## Pass in the full path to the executable as $1
if [[ "${USER}" != "root" ]] ; then
/bin/echo
/bin/echo "*** This application must be run as root. Please authenticate below. ***"
/bin/echo
sudo "${1}" && exit 0
fi
}
RemoveAD(){
# This function force-unbinds the Mac from the existing Active Directory domain
# and updates the search path settings to remove references to Active Directory
searchPath=`/usr/bin/dscl /Search -read . CSPSearchPath | grep Active\ Directory | sed 's/^ //'`
# Force unbind from Active Directory
/usr/sbin/dsconfigad -remove -force -u none -p none
# Deletes the Active Directory domain from the custom /Search
# and /Search/Contacts paths
/usr/bin/dscl /Search/Contacts -delete . CSPSearchPath "$searchPath"
/usr/bin/dscl /Search -delete . CSPSearchPath "$searchPath"
# Changes the /Search and /Search/Contacts path type from Custom to Automatic
/usr/bin/dscl /Search -change . SearchPolicy dsAttrTypeStandard:CSPSearchPath dsAttrTypeStandard:NSPSearchPath
/usr/bin/dscl /Search/Contacts -change . SearchPolicy dsAttrTypeStandard:CSPSearchPath dsAttrTypeStandard:NSPSearchPath
}
PasswordMigration(){
# macOS 10.14.4 will remove the the actual ShadowHashData key immediately
# if the AuthenticationAuthority array value which references the ShadowHash
# is removed from the AuthenticationAuthority array. To address this, the
# existing AuthenticationAuthority array will be modified to remove the Kerberos
# and LocalCachedUser user values.
AuthenticationAuthority=$(/usr/bin/dscl -plist . -read /Users/$netname AuthenticationAuthority)
Kerberosv5=$(echo "${AuthenticationAuthority}" | xmllint –xpath 'string(//string[contains(text(),"Kerberosv5")])' -)
LocalCachedUser=$(echo "${AuthenticationAuthority}" | xmllint –xpath 'string(//string[contains(text(),"LocalCachedUser")])' -)
# Remove Kerberosv5 and LocalCachedUser
if [[ ! -z "${Kerberosv5}" ]]; then
/usr/bin/dscl -plist . -delete /Users/$netname AuthenticationAuthority "${Kerberosv5}"
fi
if [[ ! -z "${LocalCachedUser}" ]]; then
/usr/bin/dscl -plist . -delete /Users/$netname AuthenticationAuthority "${LocalCachedUser}"
fi
}
RunAsRoot "${0}"
# Check for AD binding and offer to unbind if found.
if [[ "${check4AD}" = "Active Directory" ]]; then
/usr/bin/printf "This machine is bound to Active Directory.\nDo you want to unbind this Mac from AD?\n"
select yn in "Yes" "No"; do
case $yn in
Yes) RemoveAD; /bin/echo "AD binding has been removed."; break;;
No) /bin/echo "Active Directory binding is still active."; break;;
esac
done
fi
until [ "$user" == "FINISHED" ]; do
/usr/bin/printf "%b" "\a\n\nSelect a user to convert or select FINISHED:\n" >&2
select netname in $listUsers; do
if [ "$netname" = "FINISHED" ]; then
/bin/echo "Finished converting users to local accounts"
exit 0
fi
accounttype=`/usr/bin/dscl . -read /Users/"$netname" AuthenticationAuthority | head -2 | awk -F'/' '{print $2}' | tr -d '\n'`
if [[ "$accounttype" = "Active Directory" ]]; then
mobileusercheck=`/usr/bin/dscl . -read /Users/"$netname" AuthenticationAuthority | head -2 | awk -F'/' '{print $1}' | tr -d '\n' | sed 's/^[^:]*: //' | sed s/\;/""/g`
if [[ "$mobileusercheck" = "LocalCachedUser" ]]; then
/usr/bin/printf "$netname has an AD mobile account.\nConverting to a local account with the same username and UID.\n"
else
/usr/bin/printf "The $netname account is not a AD mobile account\n"
break
fi
else
/usr/bin/printf "The $netname account is not a AD mobile account\n"
break
fi
# Remove the account attributes that identify it as an Active Directory mobile account
/usr/bin/dscl . -delete /users/$netname cached_groups
/usr/bin/dscl . -delete /users/$netname cached_auth_policy
/usr/bin/dscl . -delete /users/$netname CopyTimestamp
/usr/bin/dscl . -delete /users/$netname AltSecurityIdentities
/usr/bin/dscl . -delete /users/$netname SMBPrimaryGroupSID
/usr/bin/dscl . -delete /users/$netname OriginalAuthenticationAuthority
/usr/bin/dscl . -delete /users/$netname OriginalNodeName
/usr/bin/dscl . -delete /users/$netname SMBSID
/usr/bin/dscl . -delete /users/$netname SMBScriptPath
/usr/bin/dscl . -delete /users/$netname SMBPasswordLastSet
/usr/bin/dscl . -delete /users/$netname SMBGroupRID
/usr/bin/dscl . -delete /users/$netname PrimaryNTDomain
/usr/bin/dscl . -delete /users/$netname AppleMetaRecordName
/usr/bin/dscl . -delete /users/$netname PrimaryNTDomain
/usr/bin/dscl . -delete /users/$netname MCXSettings
/usr/bin/dscl . -delete /users/$netname MCXFlags
# Migrate password and remove AD-related attributes
PasswordMigration
# Refresh Directory Services
if [[ ${osvers} -ge 7 ]]; then
/usr/bin/killall opendirectoryd
else
/usr/bin/killall DirectoryService
fi
sleep 20
accounttype=`/usr/bin/dscl . -read /Users/"$netname" AuthenticationAuthority | head -2 | awk -F'/' '{print $2}' | tr -d '\n'`
if [[ "$accounttype" = "Active Directory" ]]; then
/usr/bin/printf "Something went wrong with the conversion process.\nThe $netname account is still an AD mobile account.\n"
exit 1
else
/usr/bin/printf "Conversion process was successful.\nThe $netname account is now a local account.\n"
fi
homedir=`/usr/bin/dscl . -read /Users/"$netname" NFSHomeDirectory | awk '{print $2}'`
if [[ "$homedir" != "" ]]; then
/bin/echo "Home directory location: $homedir"
/bin/echo "Updating home folder permissions for the $netname account"
/usr/sbin/chown -R "$netname" "$homedir"
fi
# Add user to the staff group on the Mac
/bin/echo "Adding $netname to the staff group on this Mac."
/usr/sbin/dseditgroup -o edit -a "$netname" -t user staff
/bin/echo "Displaying user and group information for the $netname account"
/usr/bin/id $netname
# Prompt to see if the local account should be give admin rights.
/bin/echo "Do you want to give the $netname account admin rights?"
select yn in "Yes" "No"; do
case $yn in
Yes) /usr/sbin/dseditgroup -o edit -a "$netname" -t user admin; /bin/echo "Admin rights given to this account"; break;;
No ) /bin/echo "No admin rights given"; break;;
esac
done
break
done
done

view raw

gistfile1.txt

hosted with ❤ by GitHub

The script is 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

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;}’
    logout
    Saving session…
    …copying shared history…
    …saving history…truncating history files…
    …completed.

    [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.

    Cheers,

  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.

    • Jon
      May 20, 2023 at 1:06 pm

      Any chance you could share this modified script? I’m not confident in modifying the script myself… It’s also not recognising my account as an AD account.

  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

  24. December 29, 2019 at 1:48 am

    I just tried this on macOS 10.15.2 and it worked a treat! Two tips:

    1.) Pull the latest version of the script from the Github link, just in case:

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

    2.) After running the script, restart into Recovery Mode (hold Command + R while rebooting), and run First Aid on your main drive.

    The second one addresses a bunch of “chown: Permission Denied” errors that crop up while the script is running. I believe that there is a specific Terminal command you can use, but it’s much simpler to just run First Aid.

  25. Matt Minde
    January 25, 2020 at 5:08 pm

    Hi Mr. Flounder & community!

    I have been looking to convert my wife’s Macbook Pro macOS 10.12.6 from a managed mobile account to a local admin account; it had been an academic computer and was passed along to her. We even went to the admin at the institution, who recommended we convert the account. He approved this script, in principle. I’ve tried to run it from both the account to be converted as well as a separate Admin account set up specifically to try to change the password — all to no avail. I keep getting these permission errors, pasted below. I know very little about command line work, and as such do not know where to go next. Any help would be greatly appreciated! THANKS!

    Converting to a local account with the same username and UID.
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    attribute status: eDSPermissionError
    DS Error: -14120 (eDSPermissionError)
    No matching processes belonging to you were found
    Something went wrong with the conversion process.
    The jberman account is still an AD mobile account.
    logout
    Saving session…
    …copying shared history…
    …saving history…truncating history files…
    …completed.

    • Charles
      October 5, 2020 at 6:55 pm

      I had the same issue. I did the following:
      chmod u+x /path/to/file.command
      sh /path/to/file.command

      In my case, path was /users/myusername/file.command. Running the command like this sh file.command would create a command not found but still running the script with error.

  26. Ryan Mak
    March 1, 2020 at 11:07 am

    How do I run this script?

  27. May 8, 2020 at 11:08 pm

    Confirmed this is running correctly on OS X 10.15.4

  28. Lindsay Vogel
    June 9, 2020 at 6:35 pm

    We have used this script without issue in the past, but recently cannot get it to work with a 10.15.5 machine. When we run the script, no users appear in the list, it just says FINISHED. Any tips? I’ll take any advice, criticism, opinions, help, etc at this time!

  29. William
    July 23, 2020 at 12:01 pm

    As someone commented before, I’m trying to compile this in Script Editor, but getting Syntax Error Expected expression but found unknown token. on this line:

    FullScriptName=’basename “$0″‘

  30. Eric
    October 14, 2020 at 10:08 pm

    Hello everyone,

    I ran this on macOS Catalina (10.15.7). When the script got to the point where it’s supposed to show the list of users, it just had the option of FINISHED, so I selected that, since it was not detecting the AD user I wanted to convert to a local account. I rebooted the computer and logged back in with the local root account. The computer had in fact been unjoined from AD, so I can no longer login as that AD user, and I can’t access those files due to permissions either.

    One thing I want to point out is that the computer was joined to AD, but, I did not have the “mobile” option checked, since this was a MAC mini and it did not require the mobile option.

    Has anyone run into this issue?

    • October 14, 2020 at 10:19 pm

      An AD mobile account is a network user where a cached copy of the account information and credentials are kept on the Mac for those times when the Mac is unable to communicate with an AD domain controller.

      If your account was not a mobile account, that network account did not cache a copy of its information and would need to contact the domain controller on login and whenever the Mac needed to access information related to that network account. Since the Mac has been unbound from AD, the Mac doesn’t have anywhere to look up information about the AD account in question. From the Mac’s perspective, once disconnected from AD, that account stopped existing (though the account’s home directory still exists on that Mac.)

      This script is designed to look for and migrate that cached network account (aka a mobile account) to a local account. No mobile account = nothing to migrate.

  31. R.Manikandan
    February 8, 2021 at 2:06 pm

    nice to do this and do we have any option like FileVault and keychain password sync from the AD account without deleting the mobile account and other changes

  32. Dan Miller
    April 16, 2021 at 6:40 pm

    Is there any way to modify this script to migrate an existing LOCAL user to the “new” NoLoAd local user? We have always had generic logins, are starting to use NoMAD and would like to migrate the old generic user to the new NoMAD/AD-linked one .

  33. Fabio
    November 9, 2021 at 1:31 pm

    it works on BigSur too
    applied First Aid step as suggested by @jwcounts

  34. Mehdi Yawari
    November 11, 2021 at 5:39 pm

    I am also using this Script on many of my mac (macos =<Catalian).
    It works perfectly. I have edited this script so, that it could be run without user interaction.
    but I need to change the UID of the domain user. is there any script, that you guys can recommend? So that i could implement it in this script without destroying anything.
    And does changing UID have any other effects on the mac? (regarding HomeDirectory Permissions).
    After changing the UID i wasnt able to access the HD.
    @rtrouton

  35. STUBAKKA
    March 16, 2022 at 6:36 pm

    Would this work with MacOS 12? heading towards a JAMF connect engagement, would be useful as the Macs are bound to AD currently with Nomad in place.

    • Chris
      March 28, 2022 at 4:23 am

      It does work with macOS 12, we’ve started using it since that came out because SecureToken was causing accounts (with passwords changed off-Mac) to be locked out.
      The only issue I have found (and just found) is that we have some users with IDs below 500 and that seems to be a problem for FileProvider (at least for OneDrive)

  1. No trackbacks yet.

Leave a comment