[Samba] HOW TO: Migrating users' locally-stored profiles from one domain or workgroup to a new domain

[Jonathan Johnson]

Migrating Users Profiles When Changing Domain Affiliation: A Primer


I. Introduction

NOTE: This applies to Windows NT-based systems with locally-stored user
profiles. Windows 9x and Me do not manage user profiles in the same way.

Quite often we find the need to change a workstation's affiliation,
either from a workgroup (that is, the workstation is not in a domain
environment) to a domain, from one domain to another, or perhaps we need
to remove a workstation from a domain and have it rely on local user
authentication. The problem is that in any of these scenarios,
established users finds that they have lost access to their locally
stored profiles; a new profile is created for them when they log in to
the new domain. They need to re-establish the icons on their desktops,
they need to re-establish rights on that computer, and they need to copy
their personal files (i.e., My Documents) from the old profile to the
new one. This is a recipe for a headache and ill feelings toward the
network administrator.

The traditional solution has been to use roaming profiles, but this is
not always convenient or practical, and sometimes something breaks and
that tactic doesn't work. There is another method that I've developed
which seems to work pretty well. It involves messing with permissions
and the registry, so caveat administrator.


II. Active Directory Migration Tool: The Microsoft Way

Microsoft provides the Active Directory Migration Tool (ADMT) for
migrating user accounts, groups, and machine accounts from one domain to
another as an installable tool from the Windows Server 2003 CD. You can
also download it from Microsoft; go to http://download.microsoft.com/
and search for ADMT. I have used it on several occasions for migrating
accounts between Windows domains (NT to 2003, 2000 to 2003, and even
Samba to 2003). I do not believe it would work for migrating from a
Windows domain to a Samba domain, but I've never tried it. Perhaps some
intrepid administrators would like to try it out with the early versions
of Samba 4.

One of the significant advantages of using ADMT is that in addition to
migrating user, group, and machine accounts, it will dispatch to each
workstation during the computer migration phase an agent which
translates user profiles. In my observations, ADMT performs the
following tasks when migrating a machine account (assuming that user
accounts have been first migrated with the "preserve SID history" option):

1. File system rights are translated. This especially applies to user
profile folders.
2. File sharing rights are tanslated.
3. Registry hive rights are translated. This especially applies to
individual NTUSER.DAT registry hives (the core of the user profile), so
that the migrated user has full access to his or her original profile.
4. User rights and groups are translated. If a user was a member of the
local administrators group, the user will remain so in the new domain.
5. User is mapped to profle.

For machines with numerous user profiles, or for a network with a large
number of workstations, ADMT saves the administrator a lot of time, as
these tasks are fully automated. Since we are using Samba, we can't use
ADMT to translate user rights and migrate these items to the new domain.
We must do this manually.


III. Manual Migration of Local User Profiles from Domain to Domain or
from Workgroup to Domain

Before joining the workstation to the new domain, it is helpful to
document the location of the profile folder of the user account we wish
to migrate. This is easily done from a command shell by typing 'echo
%userprofile%'. It is also helpful to note what local groups the user is
a member of, such as "administrators."

Once you have joined the worstation to the new domain, log in to the new
domain as the user you wish to migrate. At this time, a new profile will
be created. Make a note of this profile's folder location. The profile
folder will be deleted in a later step, but by logging in this way we
have created the registry entry that defines the user's profile in the
new domain. Log out.

Now, log in to the workstation as a local administrator. It is helpful
if the account also has domain admin priviledges.

Assign rights to the user's "old domain" local profile folder: add the
user's new domain account to filesystem security. Be sure to "reset
permissions on child objects" so subfolders and contents will have the
proper permissions.

Similarly, assign rights to any shares on this workstation that have
specific permissions applied.

Launch the registry editor. In Windows 2000 or NT, you must use
regedt32, not regedit. In Windows XP, use regedit.

Under HKEY_USERS, load the user's "old domain profile" registry hive.
This will be the NTUSER.DAT file located in the profile folder you noted
at the beginning of this exercise.

Assign permissions to this newly loaded hive such that the user's new
domain account has full access. Be sure to apply this to all child
objects. You may be presented with an error indicating that some subkey
could not be accessed; in this case you must take permissions for hive
and all child objects and reapply the permissions.

Be sure to unload the hive when you are finished.

Navigate to the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\ProfileList. Under this key will be several subkeys,
named for the SIDs of the user accounts that have logged in to this
computer. Locate the key associated with the user's new domain SID (you
can determine this SID from Samba with 'pdbedit -v user'). Change the
value of ProfileImagePath to match the profile path of the user's old
domain profile.

Close the registry editor, log out, and log in as the user to the new
domain. The user's original profile should be loaded. If you get an
error indicating that the profile could not be loaded, then you probably
did not unload the user's registry hive. Simply restart the workstation
and try again.

If all is OK, delete the now-unused "new" profile folder that was
created when you first logged in to the new domain as the user. It is
not needed.


IV. Request for 'Samba Domain Migration Tool'

Based on the information I have provided, I think that a knowledgeable
devoloper could write a tool that performs similarly to the the Active
Directory Migration Tool. ADMT is a pretty well-developed utility that
you install on a Windows server or workstation and allows you to migrate
user, group, and machine accounts from a single administrative location.

At the very least, a simple utility that you could run on a workstation
to be migrated that takes as input the old domain, the new domain, and
the user account to be migrated and performs the steps outlined above.
The "new" user profile need not be created; you should be able to create
the proper registry entries under "UserProfileList" and just have it work.

-Jon Johnson
Sutinen Consulting, Inc.
www.sutinen.com