Volume Number: 24
Issue Number: 10
Column Tag: MacEnterprise
By Greg Neagle, MacEnterprise.org
A few issues ago, we looked at implementing FileVault in an enterprise environment. FileVault is Apple's technology for securing the contents of a user's home directory. Your organization may wish to protect its users' data on company laptops, in case a laptop is lost or stolen. Using FileVault is one method to accomplish this goal.
In those earlier issues of MacTech, we looked at preparing for FileVault implementation, turning it on for a given user account, and options for managing, automating, and controlling the use of FileVault in your organization. Later, we looked at dealing with some of the day-to-day issues in dealing with FileVault-protected home directories, and methods for recovering from a lost FileVault password.
One thing not covered in the earlier articles is how you might move a FileVault-protected account and home directory from one machine to another. If you are giving a user a new machine, you may need to move his or her existing account and home directory to the new machine. For reasons best known to Apple, the Migration Assistant is of little help in this task - it refuses to migrate a FileVault user unless there are no other users on the target machine. If you have a machine built from a standard image, you may have one or more prebuilt user accounts, like a local administrative account, on the new machine and so the Migration Assistant refuses to move the FileVault-protected user account.
The advice given by the Migration Assistant is to turn off FileVault, move the account, and turn it back on. While this might work, it is problematic for several reasons:
You'll need the user's password, or at least their cooperation, to turn FileVault off. This requires more coordination between you and the user.
You'll need enough available space on the startup disk to make a duplicate of the contents of the user's FileVault-protected home folder. That space may not be available.
Decrypting and re-encrypting the FileVault-protected home directory can take a long time.
If you are using MCX to enforce FileVault, turning it off (and back on) can present a challenge, as the GUI options are disabled.
So it would be better if we could just move the FileVault-protected account as-is. Fortunately, it can be done, and really isn't that difficult - at least if you aren't afraid of the command line.
The basic ideas behind moving the FileVault account are simple:
Recreate the account information on the new machine.
Move the FileVault sparseimage or sparsebundle to the new machine.
Edit the account information to point to the FileVault disk image.
Of course, the devil is in the details. So let's get started!
If you are using mobile accounts, recreating the account is easy. Just create a new mobile account for the user - either graphically, or via the command line. In Tiger, the relevant command-line tool is MCXCacher, located in
/System/Library/CoreServices/mcxd.app/Contents/Resources/
You call it like so:
cd /System/Library/CoreServices/mcxd.app/Contents/Resources ./MCXCacher -U usershortname
which should create a new mobile account for the network user.
For Leopard, the relevant tool is called createmobileaccount. It is located in /System/Library/CoreServices/ManagedClient.app/Contents/Resources.
It's called like this:
cd /System/Library/CoreServices/ManagedClient.app cd Contents/Resources ./createmobileaccount -n usershortname
If you aren't using mobile accounts, you can manually recreate the account using the Accounts preferences pane, or the dscl command-line utility, but be sure the shortname, uid, and GeneratedUID of the recreated account match the original. The dscl utility can be of great help here, allowing you to read the appropriate values from the old account and write them to the new one:
oldmac:/ root# dscl . read /Users/localuser uid dsAttrTypeNative:uid: 4389 newmac:/ root# dscl . create /Users/localuser uid 4389
Another challenge, if you are not using mobile accounts, is copying the stored password from the old account and machine to the new one, but this, too, can be done. The passwords are stored in /private/var/db/shadow/hash. For local accounts, the shadow files are named after the GeneratedUID of the user account:
root# dscl . read /Users/localuser GeneratedUID GeneratedUID: 1DECD42B-52EB-4B89-B2B2-359F0623EB1F
So for "localuser" above, the password is stored in /private/var/db/shadow/hash/1DECD42B-52EB-4B89-B2B2-359F0623EB1F. To copy the password hash from the old machine to the new one, you'd just copy that file.
The next step is easier. All you need to do is copy the FileVault disk image from the old machine to the new one. But first, let's do some prep work. If you recreated the account on the new machine, you may have a folder in /Users that is partially populated. We don't really need the contents of this folder, as we're going to replace it with the FileVault disk image. If your new machine is running Tiger, or you've recreated a purely local user, just remove all the contents:
newmac:/ root# rm -rf /Users/localuser/*
If your new machine is running Leopard, and you have recreated a mobile account, you should keep the .account directory inside the user's home folder. This stores cached account info and is used by the new External Accounts in Leopard.
newmachine:/ root# ls /Users/mobileuser .CFUserTextEncoding Movies .account Music Desktop Pictures Documents Public Downloads Sites Library
You can remove everything else in the user's folder; just leave .account.
Let's look at the old machine for a second. You might see two relevant directories in /Users:
.localuser/ localuser/
If you look inside .localuser/, you'll see the sparseimage/sparsebundle. If you look in localuser/, you'll see an .autodiskmounted file. This happens when the FileVault disk image is not unmounted cleanly. The important bit is that you want to find and copy the sparseimage/sparsebundle, even if it's in a different directory than you were expecting.
One strategy to copy the FileVault disk image is to startup the old machine in FireWire target disk mode, connect it to the new machine, and use sudo cp or ditto to copy the sparseimage/sparsebundle. If you do this, it's probably a good idea to uncheck the "Ignore ownership" box in the Get Info window for the FireWire-connected volume. If you don't do this, you can manually reassign ownership of the FileVault image after the copy.
cp -pvr /Volumes/oldmac/Users/myuser/myuser.sparsebundle \ /Users/myuser/myuser.sparsebundle chown -R myuser /Users/myuser/myuser.sparsebundle
If you cannot abide the command line, it is possible to do this completely from the Finder, but you'll need to first change the permissions and/or ownership of the various directories so you can read and write. Be sure to change ownership and permissions back when you are done copying.
When you are done copying, you should have a username.sparsebundle or username.sparseimage in /Users/username on the new machine. /Users/username and /Users/username/username.sparsebundle should be owned by username, and the owner should have read, write and execute permissions:
chown -R username /Users/username chmod -R u+rwX /Users/username
We're almost there! We've recreated the account, and we've copied the FileVault disk image. But the recreated account has the wrong value for the HomeDirectory attribute. We need to fix that. While previous steps could be done without using the command line, I'm afraid that for this task you have no choice but to fire up the terminal.
newmac:/ root# dscl . read /Users/myuser HomeDirectory No such key: HomeDirectory
For a "normal" non-FileVault encrypted home directory, this attribute does not exist (the NFSHomeDirectory attribute does exist, but that's a different thing...) We need to create this attribute and point it to the FileVault disk image.
dscl . create /Users/myuser HomeDirectory '<home_dir><url>file://localhost/Users/myuser/myuser.sparsebundle</url></home_dir>'
The above command should be all one line. Substitute the correct username for "myuser" and in "myuser.sparsebundle". If the encrypted home directory is in the older FileVault format, substitute "sparseimage" for "sparsebundle".
If you did everything right, the user should now be able to log in on their new machine with their username and password and access their FileVault-encyrpted home directory. And maybe you've learned some things about FileVault, mobile accounts and the Directory Service along the way.
To review:
We recreated the user account on the new machine, using MCXCacher or createmobileaccount if the account was a mobile account; or manually if it was a local account, ensuring the shortname, uid, and GeneratedUIDs matched.
For local accounts, we copied the shadow password file. (Recreating a mobile account generates this for us automatically)
We copied the FileVault disk image from the old machine to the new one.
We edited the local accounts' HomeDirectory attribute to point to the FileVault disk image.
That was a lot of work - but should have been faster than turning FileVault off, moving the account and data, and then turning it back on. Additionally, the user's password was not needed to move the account and data. Once you get this technique down, you might consider writing a script to do most of it for you, which is, of course, what I've done. Better would be to help persuade Apple to update the Migration Assistant to do this: if we can do it, so could the Migration Assistant!
Greg Neagle is a member of the steering committee of the Mac OS X Enterprise Project (macenterprise.org) and is a senior systems engineer at a large animation studio. Greg has been working with the Mac since 1984, and with OS X since its release. He can be reached at gregneagle@mac.com.
