Background Information for Restructuring Active Directory Domains Within a Forest

Updated: September 29, 2013

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

Applies to: Active Directory Migration Tool 3.2 (ADMT 3.2)

Restructuring Active Directory domains within a forest involves migrating accounts and resources from the source domains to the target domains. Unlike the process for restructuring Active Directory domains between forests, when you restructure domains in a forest, the migrated objects no longer exist in the source domain.

noteNote
For intraforest migration, computer accounts are treated differently than user and group accounts. To facilitate rollback, a new computer account is created in the target domain, and the source computer account remains enabled in the source domain after the migration.

In addition, migrating user accounts, resources, and groups requires special consideration when you restructure Active Directory domains within a forest because of the containment rules that apply to Active Directory groups. For these reasons, the challenge when you restructure Active Directory domains in a forest is to ensure that users have continuous access to resources during the migration process.

When you restructure Active Directory domains within a forest, you must be concerned with two types of closed sets:

  • Users and groups

  • Resources and local groups

The first type of closed set includes the following:

  • User accounts

  • All the global groups to which the users belong

  • All the other members of the global groups

Global groups are limited to members of the domain where the global group exists. Therefore, if you migrate a user account to a new domain but you do not migrate the global groups to which the user belongs, the user is no longer a valid member of those global groups and the user cannot access resources that are based on membership in those global groups. Therefore, when you are moving accounts between domains in a forest, it is necessary to move closed sets so that users retain access to their resources.

Although built-in accounts (such as Administrators, Users, and Power Users) and well-known accounts (such as Domain Admins and Domain Users) cannot be Active Directory Migration Tool (ADMT) migration objects, migrating these groups in closed sets is not a common problem. Using them in access control lists (ACLs) or membership in domain local groups is not an effective way to assign resource permissions.

When you migrate users, ADMT makes the user a member of the domain users group in the target domain. However, it does not maintain permissions for other built-in groups (such as Server Operators and Backup Operators) or well-known groups (such as Domain Admins). If you have used built-in or well-known groups to assign resource permissions, you must reassign those permissions to a new domain local group before you begin the migration. Reassigning permissions includes performing the following steps:

  1. Create a new domain local group in the source domain.

  2. Create a new global group in the source domain that contains users who need access to the resource.

  3. Add the new global group to the domain local group.

  4. Run security translation by using a security identifier (SID) mapping file that maps the well-known group to the new domain local group (created in the first step) on all resources that assign permissions using well-known groups. For information about performing a security translation by using a SID mapping file, see Translate Security by Using a SID Mapping File, later in this guide.

In small domain environments that have few global groups, you might be able to identify closed sets of users and groups. If you can identify closed sets, you can migrate users and groups at the same time. In a large domain environment, a user can belong to a number of global groups. Therefore, it is difficult to identify and migrate only closed sets of users and groups. For this reason, it is best to migrate groups before you migrate user accounts.

For example, User 1 belongs to global groups Global A and Global B and is a member of Domain 1. If an administrator moves User 1 and Global A to Domain 2 in the same forest, these accounts no longer exist in Domain 1. They exist only in Domain 2 in the same forest. Global B group remains in Domain 1. This creates an open set, or a set that includes users and groups in more than one domain. Because global groups can only contain members from the domain where the global group exists, the membership of User 1 in Global B is no longer valid, and User 1 can no longer access resources based on membership in Global B. Therefore, it is best to migrate both global groups before you migrate User 1.

ADMT transforms the global group into a universal group so that it can contain users from other domains and retain the group membership. When the set becomes a closed set, ADMT changes the group back to a global group. The benefit of this process is that ADMT ensures that all closed set problems are resolved. However, replication of the global catalog is increased while the groups are universal groups because membership is copied to the global catalog.

The second type of closed set is resources and local groups. In most cases, resources have permissions assigned to computer local groups or domain local groups. Because computer local groups are migrated when you migrate the computer, these groups are a natural closed set. However, domain local groups can be used on multiple computers to assign permissions.

In this case, you can either migrate all the computers that use the domain local group at the same time that the domain local group is migrated to the target domain or you can manually change the domain local group to a universal group and then migrate the universal group. Changing the domain local group to a universal group is a manual process because ADMT does not automatically perform this task. Although this change can increase the size of your global catalog, over a limited time period, it is an effective way to migrate resources and domain local groups as a closed set.

SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you use ADMT to migrate objects between domains in the same forest, the SID history is automatically retained. In this way, the SID from the source domain remains as an attribute of the object after the object is migrated to the target domain.

For example, an organization that is restructuring its Active Directory domains moves universal and global groups from a source domain to the target domain before moving user accounts. This is a migration within a forest, so these groups cease to exist in the source domain and exist only in the target domain. But the SID history of both users and groups is migrated, so the users continue to have access to resources in the source domain based on their membership in a group that exists in the target domain.

The most effective way to assign permissions to resources is to perform the following actions:

  1. Assign users to global groups

  2. Place global groups within domain local groups

  3. Assign permissions to the domain local groups

Assigning permissions to resources in this way simplifies the migration process.

Community Additions

ADD
Show: