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.
As part of a domain migration project, I was recently tasked with figuring out a way to handle migrating the Macs from one AD domain to another. I had the following requirements:
- Unbind the Mac from the old AD domain
- Bind the Mac to the new AD domain
- Migrate the user’s data from the old AD domain to the new AD domain
Preferably, it would be a procedure that anybody could use. That way, anyone on the team could be perform the migration process regardless of their personal skill level with Macs.
I had a pre-existing interactive script that I could modify and use to fulfill requirement 3, but I needed a way to fulfill requirements 1 and 2.
With some help from DeployStudio, I was able to develop an unbind / rebind procedure that fulfilled requirements 1 and 2. It also gave me the following features:
- Anyone on our helpdesk team could do it, regardless of familiarity with Macs or Active Directory.
- Potential for human error was minimized
- Reboots (generally a good idea when making directory service changes) were a built-in part of the migration process.
For details, see below the jump.
While developing a process to make it relatively easy for a someone with little Mac experience to unbind and rebind a Mac to an Active Directory domain, I ran across an interesting problem.
I wanted to use Apple’s dsconfigad tool but it wants to have a user account and password either specified as part of the command, or have the command specify a username and it will then prompt for the password. Since I was going to be scripting this, that meant that I would need to put the password in the clear.
While I was puzzling in IRC over the issue of a) putting an AD admin password in the clear for anyone with access to the script or b) attempting to remove the binding files and deal with the issues there, Tim Sutton asked a simple question: “Did you try giving a bogus user?”
No. I hadn’t.
As it turns out, if you’re forcing an unbind, dsconfigad only cares if you give it a user and password. It apparently doesn’t care whether the account actually exists in AD. Running the following command with root privileges will work fine to force a Mac to unbind from AD:
dsconfigad -force -remove -u johndoe -p nopasswordhere
Note: Running this command will only unbind the Mac. It does not remove the computer object from your Active Directory domain.
Every so often, a user may call the help desk to report that they can’t log into their Mac using their Active Directory account’s username and password. Here’s a way to diagnose remotely if their workstation is having an AD problem and needs to be re-bound.
1. Use SSH to remotely connect to the Mac in question: ssh email@example.com
This message may appear if it’s the first time connecting from your workstation to the remote Mac:
The authenticity of host ‘workstation-name.domain.org (ip.address.here)’ can’t be established.
RSA key fingerprint is 47:15:1f:e0:b1:dc:05:25:2c:cf:ae:aa:8c:ac:83:c3.
Are you sure you want to continue connecting (yes/no)?
Enter yes when prompted and hit Return.
A while back, I had posted an AppleScript that Peter Bukowinski and I had built to provide an easy-to-use way to look up the location of an Active Directory home folder. With the changes to the Active Directory plug-in on Mac OS X 10.7.x, the script also needed to be updated so I’m posting the updated script and code. The script should be usable on AD-bound 10.6.x and 10.7.x Macs, and Peter has added some new functionality to display the correct fileshare connection information for both Macs and Windows boxes.
In order to work correctly, the script needs for the Mac to be bound to an AD domain. The AD-bound Mac also needs to be connected to the AD domain via a domain-reachable network connection or via VPN.
Using the script:
Launch the script and provide the username in the blank provided, then click OK.
The home folder’s address will then be displayed in a dialog box, with the correct fileshare information for both Windows and Mac. You’ll also be prompted to copy the home folder information to the Mac’s clipboard for pasting (if needed.) Click OK to dismiss the dialog without copying the information. Clicking any of the buttons will quit the script.
As before, it should be pretty generic but the only location I’ve tested it at is here at my workplace. If you’re planning to use it on 10.7.x AD-bound Macs, check the code as you will need to make some edits.
Due to the way that FileVault 2 handles logins, with the user logging in at the pre-boot login screen and then brought directly into their account, users with Active Directory accounts will not get the password expiration warning that normally appears at the login window.
If you need to have those notifications in your environment, Peter Bukowinski’s ADPassMon is a great freeware utility for showing your users how long they have until their AD password expires. It launches and runs after the user logs in, so it’s unaffected by FileVault 2’s handling of the login process.
For complete information on this utility, see the ADPassMon product page.
As part of getting of getting my shop ready to support 10.7, I’ve made some updates to the interactive MigrateLocalUsertoADDomainAcct that I have posted to my GitHub repositiory. The script (adapted from the original by Patrick Gallagher) helps you migrate a local user account to an equivalent AD domain account.
If you need this for your own shop, feel free to download a copy.
Direct link to script and README: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/migrate_local_user_to_AD_domain