Background Information for Restructuring Active Directory Domains Within a Forest

Article
06/06/2011

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

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 within a forest, the migrated objects no longer exist in the source domain. Additionally, 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 within a forest is to ensure that users have continuous access to resources during the migration process.

Active Directory Migration Tool

The Active Directory Migration Tool (ADMT) version 2 allows you to migrate objects within Active Directory forests. ADMT includes wizards that automate migration tasks such as migrating users, groups, service accounts, computers, and trusts, and performing security translation.

ADMT is available in the Admigration.msi file in the \i386\admt directory on the Windows Server 2003 operating system CD.

You can perform ADMT tasks by using the ADMT console, a command line, or a script. When running ADMT at the command line, it is often more efficient to use an option file to specify command-line options. You can use the ADMT option file reference shown in Listing 12.1 to assist you in creating option files. Examples of command-line syntax are provided for each task that you must perform to restructure the domains within the forest.

Listing 12.1 lists common options that apply to several migration tasks. Each type of migration task has a section that lists options that are specific to that task. The section name corresponds to the task name when you run ADMT at the command line. Items can be commented out with a semi-colon. In Listing 12.1, the default values are commented out.

When running ADMT at the command line, you do not need to include an option in your command if you want to accept the default value. In this chapter, however, tables are provided for reference. The tables list the command-line equivalent of each option that is shown in the corresponding ADMT console procedure, including those where you are accepting the default value.

Listing 12.1 ADMT Option File Reference

 [Migration]
;TestMigration=No
;IntraForest=No
SourceDomain=" source_domain_name"
;SourceOu=" source_ou_path"

TargetDomain=" target_domain_name"
TargetOu=" target_ou_path"
;RenameOption=Dont
;RenamePrefixOrSuffix=""
;PasswordOption=Complex
;PasswordServer=""
;PasswordFile=""
;ConflictOptions=Ignore
;ConflictPrefixOrSuffix=""
;UserPropertiesToExclude=""
;InetOrgPersonPropertiesToExclude=""
;GroupPropertiesToExclude=""
;ComputerPropertiesToExclude=""

[User]
;DisableOption=EnableTarget
;SourceExpiration=None
MigrateSIDs=Yes
;TranslateRoamingProfile=No
;UpdateUserRights=No
;MigrateGroups=No
;UpdatePreviouslyMigratedObjects=No
;FixGroupMembership=Yes
;MigrateServiceAccounts=No
;UpdateGroupRights=No

[Group]
MigrateSIDs=Yes
;UpdatePreviouslyMigratedObjects=No
;FixGroupMembership=Yes
;UpdateGroupRights=No
;MigrateMembers=No
;DisableOption=EnableTarget
;SourceExpiration=None
;TranslateRoamingProfile=No
;MigrateServiceAccounts=No

[Security]
TranslationOption=Add
;TranslateFilesAndFolders=No
;TranslateLocalGroups=No
;TranslatePrinters=No
;TranslateRegistry=No
;TranslateShares=No
;TranslateUserProfiles=No
;TranslateUserRights=No
;SidMappingFile=" SidMappingFile.txt"

For a file that includes common options that are available for ADMT, see "ADMT Option File Reference" (DSSRENT_3.txt) on the Microsoft® Windows® Server 2003 Deployment Kit companion CD (or see "ADMT Option File Reference" on the Web at https://www.microsoft.com/reskit).

When running ADMT from the command line, it is often more efficient to use an include file to list the users, groups, or computers that will be migrated. For example, to migrate a small number of computers, you might type each computer name at the command line, using the /N option as follows:

ADMT COMPUTER /N “computer_name1” “computer_name2” /IF:YES /SD:”source_domain” /TD:”target_domain” /TO:”target_OU”

Computer_name1 and computer_name2 are the names of computers in the source domain that you are migrating in this batch.

If you have a large number of users, groups, or computers to migrate, you can list them in an include file. For example, to create an include file for a batch of computers, create a plain text file and list the computer names, each name on a separate line. Then specify the include file name with the /F option, as follows:

ADMT COMPUTER /F “includefile_name” /IF:YES /SD:”source_domain” /TD:”target_domain” /TO:”target_OU”

ADMT supports the use of American National Standards Institute (ANSI) or standard Unicode files for option files and include files.

To specify the names of users, groups, or computers, use one of the following conventions:

The Security Accounts Manager (SAM) account name. Note that to specify a computer name in this format, you must append a $ to the computer name. For example, to specify a computer with the name Workstation01, use Workstation01$.
The Windows NT 4.0 account name. This includes the domain name and the SAM account name. For example, the Windows NT 4.0 account name of a computer named Workstation01 that is in the Asia domain is Asia\ Workstation01$.
The relative distinguished name (also known as RDN). For example, cn= Workstation01.
The canonical name. This can be specified as DNS domain name/ou_path/object_name, or ou_path/object_name; for example, Asia.trccorp.treyresearch.net/Computers/ Workstation01 or Computers/Workstation01.

For a complete list of all available ADMT options and syntax, run ADMT, and then select Help on the menu.

The sample scripts provided in this chapter reference the symbolic constants that are defined in the AdmtConstants.vbs file. Listing 12.2 shows the ADMT constants VBScript file.

Listing 12.2 ADMT Scripting Constants

Option Explicit

'----------------------------------------------------------------------------
' ADMT Scripting Constants
'----------------------------------------------------------------------------

' RenameOption constants

Const admtDoNotRename      = 0
Const admtRenameWithPrefix = 1
Const admtRenameWithSuffix = 2

' PasswordOption constants

Const admtPasswordFromName = 0
Const admtComplexPassword  = 1
Const admtCopyPassword     = 2

' ConflictOptions constants

Const admtIgnoreConflicting           = &H0000
Const admtReplaceConflicting          = &H0001
Const admtRenameConflictingWithPrefix = &H0002
Const admtRenameConflictingWithSuffix = &H0003
Const admtRemoveExistingUserRights    = &H0010
Const admtRemoveExistingMembers       = &H0020
Const admtMoveReplacedAccounts        = &H0040

' DisableOption constants

Const admtEnableTarget       = 0
Const admtDisableSource      = 1
Const admtDisableTarget      = 2
Const admtTargetSameAsSource = 4

' SourceExpiration constant

Const admtNoExpiration = -1

' Translation Option

Const admtTranslateReplace = 0
Const admtTranslateAdd     = 1
Const admtTranslateRemove  = 2

' Report Type

Const admtReportMigratedAccounts  = 0
Const admtReportMigratedComputers = 1
Const admtReportExpiredComputers  = 2
Const admtReportAccountReferences = 3
Const admtReportNameConflicts     = 4

' Option constants

Const admtNone     = 0
Const admtData     = 1
Const admtFile     = 2
Const admtDomain   = 3
Const admtRecurse           = &H0100
Const admtFlattenHierarchy  = &H0000
Const admtMaintainHierarchy = &H0200

For a script file that includes the constants that are available for ADMT scripts, see "ADMT Scripting Constants" (AdmtConstants.vbs) on the Windows Server 2003 Deployment Kit companion CD (or see "ADMT Scripting Constants" on the Web at https://www.microsoft.com/reskit). The constants are also provided on the Windows Server 2003 operating system CD, in the TemplateScript.vbs file in the \i386\admt directory.

Closed Sets and Open Sets

When you restructure Active Directory domains within a forest, you must be concerned with two types of closed sets. The first type is users and groups, and the second type is resources and local groups.

The first type of closed set includes user accounts, all the global groups to which the users belong, and all the other members of the global groups. Because global groups are limited to members of the domain where the global group exists, if you migrate a user account to a new domain but do not migrate the global groups to which the user belongs, the user is no longer a valid member of those global groups and 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.

Built-in accounts (such as Administrators, Users, and Power Users) and well-known accounts (such as Domain Admins and Domain Users) cannot be ADMT migration objects. However, migrating these groups in closed sets is not a common problem because 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 but does not maintain permissions for other built-in groups, such as Server Operators, 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 the following steps:

Create a new domain local group in the source domain.
Create a new global group in the source domain that contains users who need access to the resource.
Add the new global group to the domain local group.
Run security translation by using a SIDmapping 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 SIDmapping file, see "Translate Security by Using a SID mapping File" later in this chapter.

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, these accounts no longer exist in Domain 1; they exist only in Domain 2. 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.

If you are migrating an open set of objects in an environment where the functional level for both the source domain and the target domain is Windows 2000 native or higher, 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 affected while the groups are universal groups because membership is copied to the global catalog.

Note

If the functional level of the source domain is Windows 2000 mixed, ADMT cannot transform the global group into a universal group because universal groups cannot exist at that functional level. Even if the target domain is in native mode, however, users in mixed mode domains would not get the SIDs of universal groups in their access tokens, if the groups are from outside the domain. Therefore, ADMT creates a copy of the global group in the target domain and adds all migrated users to the copy of that group. This group has a new security identifier (SID) and no SID history. This method does not preserve access to resources unless you run the ADMT Security Translation Wizard in Add mode to update permissions, which delays and complicates the migration process. For this reason, it is not recommended that you restructure domains that are operating at the Windows 2000 mixed functional level or the Windows Server 2003 interim domain functional level.

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 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 affect 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

SID history enables 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, 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. Because this is a migration within a forest and the functional level of the source domain is Windows 2000 native, these groups cease to exist in the source domain and exist only in the target domain. Because the SID history of both users and groups is migrated, 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.

Resource Assignment to Groups

The most effective way to assign permissions to resources is to assign users to global groups, place global groups within domain local groups, and then assign permissions to the domain local groups. Assigning permissions to resources in this way simplifies the migration process.

Terms and Definitions

The following terms apply to the process for restructuring Active Directory domains within a forest.

Migration The process of moving an object from a source domain to a target domain, while preserving or modifying characteristics of the object to make it accessible in the new domain.

Domain Restructure A migration process that involves changing the domain structure of a forest. A domain restructure can involve either consolidating or adding domains, and can take place between forests or within a forest.

Domain Consolidation A restructuring process that involves eliminating Windows NT 4.0 or Active Directory domains by merging their contents with that of other domains.