get-info -class technology | write-output > /dev/web

How to migrate users between Active Directory forests using ADMT when the source and target domain names are similar

One of my clients is undertaking a domain consolidation process, moving to a new Active Directory (AD) forest called companyname.com with two child domains – emea.companyname.com and americas.companyname.com. All of the user accounts from the various NT 4.0 and Windows 2000 domains around the organisation are being migrated into this structure using the Active Directory migration tool (ADMT) but access will be required to resources in the legacy domains (at least in the short term).

This is all reasonably straightforward, or it was until my colleagues unearthed a a new domain in Belgium called companyname.be. Because ADMT is reliant on external (NT 4.0) trust relationships, which are established using NetBIOS names (not DNS), and because emea.companyname.com already has a Kerberos trust with companyname.com, it will not allow an external trust to be created with companyname.be. We don’t want to have to recreate the users and so I had to find a way around the problem. It’s not that complex – just a two step migration, but we also needed to confirm that the sIDHistory attribute for each user would remain in place if the account was migrated more than once (in order to maintain access to resources in the original domain).

To prove this, I created four virtual machines (which run very slowly when the host is a notebook PC with only 1Gb of RAM…) representing domain controllers as follows:

dc1.companyname.com

dc2.emea.companyname.com

dc3.companyname.be

dc4.transfer.local

I created three users in companyname.be (imaginatively named user1, user2, and user3) and a share called userdata (with some test files), to which users 1 and 2 had access and user 3 was denied access. I also disabled user2 and created a group to which all three users were added as members.

The intention was to transfer the user accounts from companyname.be to transfer.local, and then to perform a second migration from transfer.local to emea.companyname.com, maintaining the account status (enabled or disabled), group membership and passwords, and then using a connection to the files on the share as a test of migrated sIDHistory.

Once I had DNS resolving names across the three forests, I installed ADMT on dc4.transfer.local and migrated the users. ADMT is fairly straightforward to set up and run, but it is necessary to read and fully understand the requirements in Microsoft knowledge base article 326480, with the main points for my client’s scenario being:

The target domain needs to be running in Windows 2000 native mode or later (without this, the sIDHistory attribute does not exist).

The computer running ADMT must be a member of either the source or the target domain.

The source domain must trust the target domain (in order for user and group migration to take place).

Administrator rights are required in both the source and target domains (e.g. by adding the target domain’s Administrator account to the source domain’s Administrators group and vice versa).

Once the above are in place, ADMT will complete some of the other requirements for user and group migration, namely:

Creating a new (empty) local group in the source domain named sourcedomainname$$$.

Enabling auditing for the success and failure of Audit account management on both domains in the Default Domain Controllers policy.

Configuring the source domain to allow RPC access to the SAM by setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport to 1 on the PDC Emulator for the source domain and restarting that server.

It should be noted that the configuration items above expose serious security weaknesses which must be secured once the migration is completed.

Once the users (with passwords) and group (with membership) had been migrated once, I could install ADMT on dc2.emea.companyname.com and migrate them again, this time from transfer.local to emea.companyname.com.

Finally, to test that the sIDHistory attribute was allowing access to resources in the original source domain (companyname.be), I logged on to dc2.emea.companyname.com and started a command prompt, from which I could issue the following commands:

net use e: \\dc3\userdata /user:emea\user1 password

(i.e. a connection to a resource in the original companyname.be domain, using an account in the emea.companyname.com domain, which as expected, allowed access to the share as well as browsing subject to file permissions on the original resources).

net use e: /del
net use e: \\dc3\userdata /user:emea\user2 password

(as expected, access was denied as the account was disabled).

net use e: /del
net use e: \\dc3\userdata /user:emea\user3 password

(as expected, a connection was made, but access was denied when an attempt was made to browse the share due to denying permissions to user3 on resources in the companyname.be domain).

net use e: /del

All of this indicated a successful migration from companyname.be to emea.companyname.com and so I decided to look a bit closer at the sIDHistory attribute which allows all of this to work.

After installing the ADSI Edit support tool from the Windows 2000 media I could see that the sIDHistory attribute had two values on the emea.companyname.com version of the object (shown in the accompanying screenshot), a single value on the transfer.local version of the object and was not present on the original companyname.be version.

Rather unhelpfully, the ADSI Edit representation of the sIDHistory is not in the usual form, but if the ldp.exe support tool is used, then by connecting to the server, binding as an administrator, and viewing the directory tree, the sIDHistory can be seen in its normal form along with the objectSID. As expected the objectSID for user1@companyname.be (S-15-78B99911-320A1743-74B49FF8-451) appeared as the sIDHistory attribute for user1@transfer.local and user1@emea.companyname.com had two values for sIDHistory – the original objectSID from user1@companyname.be (carried over in the sIDHistory from user1@transfer.local) and the objectSID from user1@transfer.local (S-15-11DA0ABB-64495118-320A1743-454).

Incidentally, had this method not worked, my colleagues and I had identified two further potential methods of migrating the users and groups which I did not try:

Install a second domain controller in companyname.be, let it replicate, take the original offline and seize the FSMO roles, then upgrade to Windows Server 2003 and rename the domain, allowing a one-step migration to to emea.companyname.com to be used. After this, the Windows Server 2003 domain controller could be taken offline and the original companyname.be Windows 2000 server brought back online (seen as a very complicated solution).

Use the clone principal utility to clone the original accounts in the new domain (workable, but requiring some scripting skills and potentially a lot of time).

After many hours of waiting for virtual machines to catch up with my mouse/keyboard, I don’t think I’ll be trying them just yet…

6 thoughts on “How to migrate users between Active Directory forests using ADMT when the source and target domain names are similar”

How did you accomplish “DNS resolving names across the three forests” in your blog post titled “How to migrate users between Active Directory forests using ADMT when the source and target domain names are similar.”? I am trying to setup Virtual PC 2007 to test migrating two Windows 2003 forests into a new Windows 2003 forest and am having problems with DNS between them, can ping the IP addresses fine.

It was nearly 3 years ago when I wrote this post, so I’m struggling to cast my mind back but I it would have been something like installing a DNS Server on each of the DCs (to support each AD installation), then getting dc2.emea.companyname.com to forward unresolved requests to dc1.companyname.com and setting up conditional forwarding on dc1.companyn.ame.com, dc3.companyname.be and dc4.transfer.local to forward requests for each domain to the respective DNS server.

Your posting is the closest I’ve seen to my requirement, but it’s not quite a fit. I wanted to run it by you for comment.

We have a stand-alone W2K FTP server. It is a member of a domain, but FTP users are all configured as local users for security reasons.

We want a stand-alone W2K3 (or perhaps W2K8) FTP server in a similar configuration. Since our 200+ FTP clients (customers / partners) have user passwords that have been “lightly” documented, if that, migrating the credentials cleanly is a high priority.

So the source is essentially a stand-alone W2K and the destination is essentially a stand-alone W2K3 / W2K8 (though they’ll actually be members of the same production domain). What’s the best strategy for migrating these local user accounts across?

And yes, we’ll want to maintain the rights and access to off-server FTP directories. But if I had to document those and recreate them via scripting, I’d be able to hack that. However, the passwords are, in some cases, simply not available and must be maintained and migrated cleanly.

A request from Mark…

I devote a lot of time to this website and the advertising doesn't even cover my hosting charges, so please don't use ad blockers that reduce this website's income (even if the ads Google serve are sometimes of dubious quality!).

I spend a lot of time creating content for this site. Please support me by adding the site us to your whitelist in your ad blocker. Thank you!

markwilson.it Cookie Policy

By using this website you allow cookies to be placed on your computer. They are harmless and never personally identify you. For more information about cookies and how they are used, visit the Privacy policy and data protection notice .