Active Directory Migration Tool

The Active Directory Migration Tool migrates objects between a source and a target domain whether they are domains in the same forest or different forests. It is available from command line with the command admt.exe. The command line version can be used with text files to automate the process. It can be used to move users, groups, computers, service accounts, and trusts. It can also perform security translation. The command line version can also help with creating Visual Basic scripts or other languages. More information about the command line version is available from the ADMT console.

With the ADMT, you can test migrations as well. The wizards will simulate the migration and allow evaluation of potential results before you actually perform the migration. After identifying and resolving any problems, you can perform the migration. The wizard that tests the settings will also provide a migrate later option that can be used for the migration. The process can repeat several times with testing and analyzing until all problems are resolved.

There is still one problem that will never be fully repaired in the migration. That problem is that SIDs will never be migrated. SIDs are unique values that are created for every computer, user, and group on any domain. As a user or computer logs on, a token is created that contains their SID and all SIDs associated with their groups. This token contains all identifiers associated with the user or computer. Security Descriptors (SD) are associated with resources. They contain information about permissions, rights, ownership, and auditing instructions. The SD consists of two parts, the SACL and the DACL. The System Access Control List (SACL) will specify auditing instructions. The Discretionary Access Control List (DACL) will specify permissions. Often the focus is on the DACL. Within the DACL, specific Access Control Entries (ACEs) can be specified with a deny or allow permission. These ACEs are linked linked to the individual SIDs. When a user or computer tries to access a resource, the Local Security Authority Subsystem (LSASS) compares the SIDs in the users token with the SIDs in the ACEs ACL.

When copying accounts from one domain to the other, new SIDs are generated for the users. Many parts of the user will appear the same such as user name, password, and group membership. However, since the SIDs are different, they are not the same user according to the resource. This problem has been resolved in one of two ways…

  • sIDHistory: sIDHistory (note capitalization.) is an attribute that was created in Windows Server 2000 domains. It allows the previous SIDs to be attached to an account as secondary SIDs. The LSASS then may check either the principal SID or the sIDHistory in the accounts token.
  • Security Translation: This process involves inspecting every Security Descriptor (SD) attached to a resource in the domain and replacing the SIDs of the previous domain user with the SIDs of the new domain user. This remapping of the resources is referred to as re-ACLing and is very labor intensive. Luckily, ADMT can perform the job of inspecting rescources and remapping them to the new SIDs of the migrated accounts. In most cases, sIDHistory is used until resources can be re-ACLed.

Another concern is group membership. Often accounts are members of global groups. Global groups are good for only members of a domain. Cross-domain membership of a group requires Universal Groups. This means that when a user is migrated to the new domain, the new user will not be a member of any groups in the old domain and will probably lose access to all resources in the old domain. (Assuming that resources are assigned using the recommended Microsoft method of AGLP.) This is solved by migrating groups first. Then when users or computers are migrated, they can be placed in the new universal groups. With sIDHistory, both groups and accounts may never notice the difference. When all changes required have been confirmed the groups may be changed back into global groups. They were made universal groups because universal groups can access resources in both domains.

Other problems with ADMT concern password migration. The ADMT can migrate passwords but the passwords for the old account may not be complex enough for the new domain’s password requirements. Service accounts may be migrated but the services may not recognize the new identity. These service accounts are ones that real people never use and may not be well known enough to remember what they do. Some objects can not be migrated such as Domain Admins or domain local administrators group. ADMT will make suggestions on how to deal with these scenarios.

Leave a Comment