This post is part of the 70-640 Articles - Windows Server 2008 Active Directory, Configuring Prep Course course.
In multidomain scenarios, you might need to move users, groups, or computers between domains or forests to support business operations. You might need to move large quantities of users, groups, or computers between domains or forests to implement mergers and acquisitions or to restructure your domain model.
In each of these tasks, you move or copy the accounts from one domain (the source domain) into another domain (the target domain). Domain restructuring terminology, concepts, and procedures apply to inter-forest migration—between a Windows NT 4.0 or Active Directory
source domain and an Active Directory target domain in a separate forest—and to intra-forest migration—that is, the restructuring or moving of accounts between domains in the same forest.
An inter-forest domain restructure preserves the existing source domain, and clones (or copies) accounts into the target domain. This nondestructive method enables an enterprise to time the transition and even migrate in phases. Operations go uninterrupted because both domains are maintained in parallel to support operations for users in either domain. This method also provides a level of rollback because the original environment remains unaltered in any significant way. After the migration is complete, you can simply decommission the source domain by moving any remaining accounts, member servers, and workstations into the new domain and then taking source DCs offline, at which point you can redeploy those DCs for roles in the new domain.
An intra-forest migration involves moving objects from the source domain to the target domain without decommissioning the source domain. After you have migrated objects, you can restructure your domains to consolidate operations and build a domain and OU structure
that more accurately reflects your administrative model. Many organizations consolidate multiple domains into one Active Directory domain. This consolidation can result in cost savings and simplified administration by reducing administrative complexity and the cost of
supporting your Active Directory environment.
Understanding the Active Directory Migration Tool
The Active Directory Migration Tool (ADMT) version 3 can perform object migration and security translation tasks. You can download ADMT v3 from http://go.microsoft.com/fwlink/?LinkID=75627. On that page, you will also find a detailed guide to the tool.
You can use ADMT to migrate objects between a source and a target domain. The migration can take place between domains in the same forest (an intra-forest migration) or between domains in different forests (an inter-forest migration). The ADMT provides wizards that automate migration tasks such as migrating users, groups, service accounts, computers, and trusts and performing security translation. You can perform these tasks by using the ADMT console or the command line, at which you can simplify and automate the Admt.exe command with option files that specify parameters for the migration task. Then, with a simple text file, you can list objects to migrate rather than having to enter each object on the command line.
ADMT also provides interfaces that allow you to script migration tasks with languages such as Microsoft Visual Basic Scripting Edition (VBScript). Run the ADMT console and open the online Help function for details about how to use ADMT from the command line and about scripting the ADMT.
When you are performing migration tasks, ADMT allows you to simulate the migration so that you can evaluate potential results and errors without making changes to the target domain. Wizards provide the Test, The Migration Settings And Migrate Later option. You can then configure the migration task, test the settings, and review the log files and wizard-generated reports. After identifying and resolving any problems, you can perform the migration task. You repeat this process of testing and analyzing results as you migrate users, groups, and computers and perform security translations.
Security Identifiers and Migration
Uninterrupted resource access is the primary concern during any migration. Further, to perform a migration, you must be comfortable with the concepts of security identifiers (SIDs), tokens, access control lists (ACLs), and sIDHistory.SIDs are domain-unique values that are assigned to the accounts of security principals—users, groups, and computers, for example—when those accounts are created. When a user logs on, a token is generated that includes the primary SID of the user account and the SIDs of groups to which the user belongs. The token thus represents the user with all the SIDs associated with the user and the user’s group memberships.
Resources are secured using a security descriptor (SD) that describes the permissions, ownership, extended rights, and auditing of the resource. Within the SD are two ACLs.
The system ACL (SACL) describes auditing. The discretionary ACL (DACL) describes resource access permissions. Many administrators and documents refer to the DACL as the ACL.
The DACL lists permissions associated with security principals. Within the list, individual access control entries (ACEs) link a specific permission with the SID of a security principal. The ACE can be an Allow or Deny permission. When a user attempts to access a resource, the Local Security Authority Subsystem (LSASS) compares the SIDs in the user’s token against the SIDs in the ACEs in the resource’s ACL.
When you migrate accounts to a new domain, the accounts are copied or cloned from the source domain to the target domain. New SIDs are generated for the accounts in the target domain, so the SIDs of new accounts will not be the same as the SIDs of the accounts in the source domain. That is, even though the cloned accounts have the same name and many of the same properties, because the SIDs are different, the accounts are technically different and will not have access to resources in the source domain. You have two ways to address this problem: sIDHistory or security translation:
– sIDHistory Enterprises typically prefer to take advantage of the sIDHistory attribute to perform effective domain restructuring. The capitalization, which appears odd, reflects the capitalization of the attribute in the Active Directory schema. An Active Directory security principal (which can be a user, group, or computer) has a principal SID and a sIDHistory attribute, which can contain one or more SIDs that are also associated with the account. When an account is copied to a target domain, the unique principal SID is generated by Active Directory in the target domain. Optionally, the sIDHistory attribute can be loaded with the SID of the account in the source domain.
When a user logs on to an Active Directory domain, the user’s token is populated with the principal SID and the sIDHistory of the user account and groups to which the user belongs. The LSASS uses the SIDs from the sIDHistory just like any other SID in the token to maintain the user’s access to resources in the source domain.
– Security translation Security translation is the process of examining each resource’s SD, including its ACLs, identifying each SID that refers to an account in the source domain and replacing that SID with the SID of the account in the target domain.
The process of re-mapping ACLs (and other elements in the SD) to migrated accounts in the target domain is also called re-ACLing. As you can imagine, security translation or re-ACLing would be a tedious process to perform manually in anything but the simplest environment. Migration tools such as ADMT automate security translation.
ADMT can translate the SDs and policies of resources in the source domain to refer to the corresponding accounts in the target domain. Specifically, ADMT can translate:
• File and folder permissions.
• Printer permissions.
• Share permissions.
• Registry permissions.
• User rights.
• Local profiles, which involves changing file, folder, and registry permissions.
• Group memberships.
In most domain restructuring and migration projects, sIDHistory is used to maintain access
and functionality during the migration; then, security translation is performed.
The final concern related to resource access is that of group membership. Global groups can
contain members only from the same domain. Therefore, if you clone a user to the target domain, the new user account cannot be a member of the global groups in the source domain to which the source user account belonged.
To address this issue in an inter-forest migration, first migrate global groups to the target domain. Those global groups will maintain the source groups’ SIDs in their sIDHistory attributes, thus maintaining resource access. Then, migrate users. As you migrate users,
ADMT evaluates the membership of the source account and adds the new account to the same group in the target domain. If the group does not yet exist in the target domain, ADMT can create it automatically. In the end, the user account in the target domain will belong to
global groups in the target domain. The user and the user’s groups will contain the SIDs of the source accounts in their sIDHistory attributes. Therefore, the user will be able to access resources in the source domain that have permissions assigned to the source accounts.
In an intra-forest migration, the process works differently. A global group is created in the target domain as a universal group so that it can contain users from both the source and the target domain. The new group gets a new SID, but its sIDHistory is populated with the SID
of the global group in the source domain, thereby maintaining resource access for the new group. After all users have been migrated from the source to the target domain, the scope of the group is changed back to global.
Other Migration Concerns
You must address several issues when planning for and executing the migration of objects between domains and forests. Each issue is detailed in the ADMT user guide, available from the ADMT download page listed earlier. Among the greatest concerns are:
– Password migration ADMT supports migrating user passwords; however, it cannot confirm that those passwords comply with the policies of the target domain regarding password length and complexity. Nonblank passwords will migrate regardless of the target domain password policy, and users will be able to log on with those passwords until they expire, at which time a new, compliant password must be created. If you are concerned about locking down the environment at the time of migration, this might not be a satisfactory process. You might, instead, want to let ADMT configure complex passwords or script an initial password and then force the user to change the password at the first logon.
– Service accounts Services on domain computers might use domain-based user accounts
for authentication. As those user accounts are migrated to the target domain, services must be updated with the new service account identity. ADMT automates this process.
– Objects that cannot be migrated Some objects cannot be seamlessly migrated. ADMT cannot migrate built-in groups such as Domain Admins or the domain local Administrators group. The user guide provides details for working around this limitation.
Note:Migrating a forest
For information on creating a new forest and migrating its contents from one forest to another, look up Windows Server 2008: The Complete Reference by Ruest and Ruest (McGraw-Hill Osborne, 2008). This book describes how to build a complete infrastructure based on Microsoft Windows Server and migrate all of its contents from one location to another.