Migrate users to a new AD forest (or domain)

I often work with  projects that must migrate users from one Active Directory forest to another. There can be many reasons for doing this; migration projects, creating test forests/domains or moving users due to compliance or security demands.

Some of these project customers often have requirements for moving all attributes and in some cases even SID (security identifier), passwords and/or groups and their members. In some cases even email addresses, aliases and security permissions for Exchange are required to be migrated (but that will be another post in the future).

There are many tools that can be used for migrating users but Microsoft ADMT version 3.2 is a useful tool (specifically for users and groups). Below is a short step by step guide to migrate users and groups cross forest.

1. Establish network infrastructure between domainsNetwork traffic must be routable between the domain controllers (preferably all DC's but at least the PDC Emulators in every domain). 
2. Establish DNS infrastructure between domainsI usually setup conditional forwarding on all DNS servers to be able to do name lookups cross forest.
3. Create one way forest trust between domainsSetup a one-way forest trust from target.com to source.com (i.e. target.com is trusted by source.com). This way you can have the migration tools in the target.com forest.
4. Install ADMT version 3.1 on TargetDC1.target.comADMT requires a SQL database for storage. If you have a SQL deployed into the domain I recommend you to use that otherwise you can install SQL Express instance to host the data.
5. Setup migration accounts
1. Create  "acct_migrators" in target.com domain (Global Security Group)
2. Add your migration account into the "Domain Admins" group in target.com
3. Add "acct_migrators" from target.com into "Administrators" in source.com
6. SID History (optional)If you require SID History you must do som additional tasks to be able to migrate source SID to target SIDHistory. This is especially useful if you also migrate services and/or files and preserve ACL's on the objects, services or servers.
1. Enable TCP/IP support on PDC emulator
   This step isn't needed if you are using Windows 2003 servers or newer.
• HKLM\System\CurrentControlSet\Control\LSA
• Modify the "TcpipClientSupport" (REG_DWORD) and set it to "1"
• Restart the DC hosting the PDC role
2. Enable auditing in target.com and source.com domains
   Edit "Default Domain Controllers policy" with the following settings;
• Computer Configuration > Polices > Windows Settings > Local Policies > Audit Policy
• Audit Account Management: Success & Failure
• Audit Directory Service Access: Success
3. Create a NETBIOSDOMAINNAME$$$ group in source.com/Users container
   This goups is a special group used during SID migration by ADMT
7. Password Export Server (PES) service (optional)
   If you need to migrate password with the user object this is possible with PES.
1. Create PES encryption key on TargetDC1.domain.com
   admt key /option:create /sourcedomain:NETBIOSDOMAINNAME /keyfile:C:\Secure\Mig.key /keypassword:*
2. Install PES server on SourceDC1.source.com
   Use a service account from target.com (NETBIOS\AccountName) and you will also need the encryption key file (and key file password) during the installation. The service is installed with "manual" as service startup (never change this)
3. Restart the DC with PES service

Migration

I recommend to migrate the groups in the following order:

1. Global groups
2. Users
3. Domain local and Universal groups

During migration of passwords remember to start the PES service on the SourceDC1.target.com server and always stop the server after the password migration to prevent attacking surface on the service.

Links

• Microsoft SQL Server 2008 SP2 Express Edition
• Active Directory Migration Tools 3.2 (ADMT v3.2)
• How to troubleshoot inter-forest sIDHistory migration with ADMTv2
• Password Export Server (PES) version 3.1 (x64)