Professor Windows - April 2002
Migrating Accounts From Windows NT 4.0 Domains to Windows 2000
By Yossi Saharon
Andreas Luther, Program Manager, Microsoft Corporation
One of the first topics that come to mind when moving to Windows 2000 Active Directory (AD) domains is the process of migrating existing resources (e.g. computer accounts, groups) from your Windows NT 4.0 domain(s) to your destination AD domain. The most interesting part of such a migration would be migrating the organization's user accounts. When choosing to install a pristine forest without performing an in-place upgrade, you can of course choose to create your resources from scratch, i.e. manually. But what if you have a big organization, with more than few users and groups? What about existing permissions to files, folders, mailboxes? Or user passwords? Re-creating all these can require significant work and time, while others (like user passwords) are simply non re-creatable.
This column tries to generally explain why using migration tools in the process of migrating your user accounts might be important for you, along with an overview of a tool called Microsoft Active Directory Migration Tool (ADMT) which can be used to perform this kind of migration. There are other third-party tools available from companies like NetIQ, Fastlane, Aelita, etc., but we will focus on ADMT.
It's important to understand that in the scope of this column we cannot cover Active Directory architecture and a deep level look of what Active Directory is.
To get more technical information on what is Active Directory and how it works, try the following link:
Directory Services technical information - http://www.microsoft.com/windows2000/technologies/directory/default.asp
Re-creating (moving or copying) large quantities of users and groups is not the only issue that migration tools can solve for you. An important aspect is migrating the user account's SID (Security Identifier), so it can continue to access existing resources without the need to redefine permissions for these resources (e.g. File Servers). When a user is created, a new SID is generated for that user account in the domain. This SID is used by the administrator to Grant/Deny access to resources and control authorization in the domain. When migrating your account, you actually create a new user account in the destination domain, thus creating another (new) SID for the newly created account.
In order to keep on accessing resources using the newly created account, an option called 'migrate sIDHistory' was introduced. This option (available in the Active Directory Migration Tool which is described later on) migrates the source account SID into an attribute called sIDHistory on the newly created user account in AD.
Having this attribute allows the new user account to log-in to the AD domain along with no interruption of accessing its 'old' resources, like, for example, an Exchange Server mailbox of that user, or a printer, or a file share. To sum up, this capability keeps your security structure (the granting and denying of access to resources) intact but conveniently brings it into the new domain.
The Active Directory Migration Tool (ADMT) is a free tool from Microsoft that can assist you with migrating your Windows NT 4.0 domain users, groups and other resources to a Windows 2000 Active Directory Forest/Domain, and more. It's important to know that the tool has a 'test mode', in which the administrator can diagnose any possible problems before actually performing the migration operations. It has task-based wizards that allow you to migrate users, groups, and computers. The tool also comes with a reporting feature for both before and after move operations.
ADMT can also be used to restructure your Windows 2000 Active Directory domains.
You don't need to install ADMT on all computers. When using ADMT to migrate users and groups, you install the ADMT tool, typically on the console in the target domain (the AD domain into which security principals or resources are being migrated). ADMT requires no additional software installation on the computers in the source domain. When moving groups, you can choose to move them along with their members to the target domain. You can choose to leave user accounts active in both the source and target domains, or create disabled accounts, and other options.
In order to move objects between domains, a trust relationship must exist between the domains. The ADMT Trust Migration wizard does this automatically by comparing the trust relationships and creating what is needed.
ADMT needs to run on a Windows 2000 Operating System. The target domain needs to be a Windows 2000 AD domain. Native mode is required in order to migrate SID and use the sIDHistory capability. The source domain can be either Windows NT 4.0 or Windows 2000. The primary domain controller (PDC) of a Windows NT 4.0 source domain must have SP4 or higher installed.
Although ADMT v2.0 is a part of Windows Server 2003 release, it fully supports Windows 2000 and can be used today to leverage new features that exist in ADMT v2.0 in a Windows NT 4.0 to Windows 2000 migration scenario. ADMT v2.0 supports Windows NT 4.0/Windows 2000/Windows Server 2003 source domains, and Windows 2000/.NET Active Directory target domains. Please Note that currently ADMT v2.0 is beta software. The RTM (Release to Manufacturer) version will likely be ready in a few months, close to the Windows Server 2003 RC1 milestone. The beta edition of ADMT v2.0 can be found on the Windows Server 2003 Beta 3 CD under \ valueadd\msft\mgmt\admt. A newer version of ADMT, build 3604, is fully supported by Microsoft Product Support Services (PSS). You can get this build through either Microsoft Consulting Services or PSS.
Some of the new features in ADMT v2.0 include:
A Scripting Interface that allows using full wizard functionality through vb scripts or any other language that works with COM interfaces. Most common wizards are implemented as scripting interfaces.
An Attribute Exclusion List for inter or intra-forest migrations allows you to define the attributes that will be excluded in a user migration.
An option to Fix users group membership allows control over the attempt to fix the migrated user's group membership, so if the Fix user group membership option is disabled, ADMT v2.0 will not attempt to recreate group memberships in the target domain. In v1.0, this was always attempted, and sometimes led to unnecessarily increased migration time.
A command-line migration is available with ADMT v2.0. Imagine how easy it is to simply install ADMT, and then open a command window and type:
admt user /n:User1 /sd:MySourceDom /td:MyTargetDom /po:complex
That's it. The account User1 will be migrated to the MyTargetDom domain.
There are more new features and improvements, yet probably the most interesting of all is the new capability to migrate user passwords.
Migrating User Passwords
Although the new capability to migrate passwords in ADMT v2.0 takes you through some additional setup steps, it is well worth it. Since default password migration options might not satisfy every organization (e.g. Same as User name, Blank passwords etc), ADMT v2.0 introduces the new Password Migration feature that allows a secure way to migrate your user accounts along with their corresponding passwords. How secure? Secure enough that no user mode process can see the password, not even the ADMT tool itself! The Password migration DLL runs in the context of LSA (Local Security Authority). Installing this DLL on the source server exposes a RPC interface that lets the newly created account to trigger a password change and relate to the source domain controller. This proposes is done by using a private key between the source password export server (PES) and the ADMT machine and requires high encryption (128-bit) on both ends. The password migration setup process is outlined in the document along with the ADMT v2.0 tool available on the Windows Server 2003 Beta 3 CD under \valueadd\msft\mgmt\admt.
For More Information
Domain Migration Cookbook (Covers ADMT v1.0 only, but helps to understand the different scenarios)
For any questions or feedback regarding the content of this column, please write to Microsoft TechNet.