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:

• Keychain password synchronization
• FileVault 2 login password synchronization

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:

• Username
• Password
• UID
• GID

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 OriginalNodeName 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:

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.