Active Directory Domain and Forest Migration Security Guide: consolidating domains without inheriting their risks

An Active Directory domain or forest migration copies accounts, group memberships and old security identifiers into the target forest, and with them every excess privilege and weak credential the source carried. Domain consolidations follow mergers, divestitures, pilot forests promoted to production and years of organic sprawl, and they are usually run as infrastructure projects under time pressure. The security risk sits in the mechanics: SID history that keeps old privileges alive, trusts relaxed for the migration and never tightened, a password export service left running on a source domain controller, and service accounts moved without anyone knowing what they do. This guide covers the security side of AD to AD migration: choosing the model, preparing the trust and SID history safely, migration order, service accounts, cutover, SID history clean-up and decommissioning the source. It is for AD architects, identity engineers and M&A integration leads. Leaving AD for a cloud directory is covered in the Retiring Active Directory guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Microsoft's Active Directory Migration Tool (ADMT) documentation is archived and was written for Windows Server 2008 to 2012 R2, so confirm tool support for your domain controller versions before you plan around it.

Key takeaways

• Migration is a trust decision first. SID history only works if the resource side honours SIDs from the migrated side, which means relaxing SID filtering on a trust. Do it for a defined window, between forests whose administrators you trust, and record when it will be reversed.
• Clone, do not inherit. An interforest migration clones objects while the source stays in place, which gives you a rollback path and a chance to drop privileged groups, stale accounts and unused rights instead of copying them.
• SID history is a temporary bridge, not a design. Every SID in sIDHistory is a privilege that does not show in group membership. Translate resource permissions to the new SIDs, then remove SID history and close the trust setting that honoured it.
• Service accounts break migrations and outlive them. Inventory them, find their owners and dependencies before cutover, and rebuild privileged ones as gMSAs in the target rather than migrating their passwords. ADMT cannot migrate group managed service accounts.
• The migration tooling is tier 0 while it runs. Migration accounts hold Domain Admins in the target and administrative rights in the source, and the Password Export Server runs on a source domain controller. Time-box all of it and remove it at the end.

Migration models and what each means for security

Microsoft's ADMT documentation distinguishes two restructure types. In an interforest restructure, objects are cloned into the target domain, the source objects stay in place and SID history and password retention are optional. In an intraforest restructure, user and group objects are moved, SID history is required and passwords are always retained. Rollback differs too: an interforest migration can be rolled back during the project because the source still exists, while an intraforest rollback means migrating back again.

Decision guidance: if there is any credible sign that the source forest is compromised, do not build a trust that honours its SID history: rebuild accounts fresh in the target and accept the user impact. If the source is healthy but messy, clone with SID history for a short window and use the migration as the clean-up. For a small organisation with one or two domains and a few hundred users, a greenfield rebuild is often cheaper and safer than a tool-driven migration. For a large estate with thousands of file shares and ACLs, SID history plus staged security translation is usually the only realistic path, which makes the clean-up phase non-negotiable.

For the business side of an acquisition (due diligence, day one access, coexistence patterns) see the Identity Integration in M&A Guide; for carve-outs see Identity separation in divestitures.

Assess the source before you trust it

A migration extends trust to the source forest. Before any trust is created, treat the source as untrusted and assess it as you would during incident response:

• Privileged groups: enumerate members of Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators and Server Operators, including nested membership. See How to find service accounts with Domain Admin rights.
• Existing SID history: query sIDHistory across the source. Microsoft's schema documentation describes it as a multivalued attribute holding previous SIDs, indexed and replicated to the global catalog, so a single LDAP query finds every populated value. Any SID history in the source that maps to a privileged RID in any domain is a red flag (ATT&CK T1134.005 SID-History Injection).
• Delegation and ACLs: unconstrained delegation, dangerous ACEs on the domain head and AdminSDHolder, and DCSync rights (T1003.006). See the Active Directory ACL and Delegation Hygiene Guide.
• Stale and service accounts: accounts with no logon for 90 days or more (an NHI Mgmt Group threshold, set your own) should be excluded from migration, not copied. See How to find stale user and computer accounts in Active Directory.
• Certificate services: a source AD CS hierarchy may issue certificates that the target will be asked to trust. See the AD CS Security Guide.
• krbtgt age: if the source krbtgt password has not been reset in years, reset it twice before the trust exists. See krbtgt account.

The output is an exclusion list (accounts and groups that will never be migrated) and a mapping of privileged source groups to deliberately designed target groups, never to the target's own Domain Admins.

Preparing trusts and SID history safely

SID history migration has specific prerequisites, documented by Microsoft for ADMT and for the underlying DsAddSidHistory function. Each one widens the attack surface, so each needs an owner and an end date.

Microsoft's DsAddSidHistory documentation also rejects some objects outright: computer accounts, trust accounts and accounts with well-known SIDs such as Administrators, Account Operators, Backup Operators and Server Operators. Well-known RID accounts such as Administrator and Domain Admins only succeed where the target principal has the same RID. A source SID must not already exist in the destination forest. Treat these rules as a floor: your exclusion list should go further and keep every privileged source group out of the migration.

Naming collides as well as SIDs: Windows Server 2012 R2 and later domain controllers block duplicate UPNs and SPNs (errors 8648 and 8467, logged as event 2974), so duplicate naming conflicts surface during test runs. Plan UPN suffixes before the first batch.

Migration order and service accounts

Microsoft's interforest checklist runs in a fixed order, and the order matters for security as well as for functionality:

1. Prepare: test plan, rollback plan, user communication plan, target OU structure with delegation designed in advance, migration accounts.
2. Service accounts: identify and transition them first (ADMT's Service Account Migration Wizard or admt service). This is where most outages and most lasting risk come from.
3. Global groups: migrate group shells so memberships can be rebuilt as users arrive.
4. Users and workstations in batches with SID history: standalone managed service accounts move with their own wizard; group managed service accounts cannot be migrated and must be recreated.
5. Resources: member servers and domain local groups.
6. Security translation in add mode: ADMT's admt security adds target SIDs to resource ACLs alongside the source SIDs (translation options are Replace, Add and Remove, applied to files and folders, shares, printers, registry, local groups, user rights and profiles).
7. Re-migrate users and workstations with profiles, then domain local groups and domain controllers.
8. Post-migration: translate security in replace or remove mode, then decommission the source.

Service accounts in practice: build the inventory from the source directory first (see How to build a service account inventory from Active Directory) and record for each one the owner, the hosts it logs on to, its SPNs, its group memberships and where its password is stored. Accounts with no owner and no recent logon are excluded. Accounts still in use are rebuilt in the target, ideally as gMSAs (see the Group Managed Service Accounts (gMSA) Guide), rather than cloned with their old password, membership and SID history. A migrated service account with SID history from a privileged source group is the single most common way old privilege survives a consolidation.

Passwords: migrating password hashes saves a reset, but it also carries forward every weak, shared and never-rotated password. Microsoft's documentation notes ADMT does not check all target password policy settings, so users are prompted to set a password after migration anyway unless "Password never expires" or smart card logon is set. For privileged and service accounts, set new passwords in the target and do not migrate hashes at all.

Cutover, testing and rollback

1. Lab rehearsal: restore a copy of both forests to an isolated lab, run the full sequence, and confirm SID history, translation and service account behaviour.
2. Pilot batch: one department with its file shares and applications. Verify that access works via the new SID before relying on SID history.
3. Batches by business unit: keep batches small enough to roll back in a day. In an interforest migration the source account stays: rollback means re-enabling the source account and disabling the target clone.
4. Source account handling: disable, do not delete, source accounts once the target clone is confirmed, and set an expiry date. Two enabled accounts for one person is a credential that will not be monitored.
5. Freeze changes: stop privileged group changes in the source during each batch so the migrated state is the reviewed state.

Removing SID history and closing the migration

The migration is not finished when the last user moves. It is finished when no access depends on old SIDs and nothing that enabled the migration remains:

1. Translate resource ACLs in replace mode so permissions reference target SIDs only.
2. Measure SID history use: before removing it, run access tests on the main file servers and applications with SID history filtered (for example, a test account without SID history). Expect a long tail in old NAS devices and line-of-business applications that store SIDs.
3. Remove sIDHistory from users, groups and service accounts in batches, after exporting the values so they can be restored during a rollback window.
4. Reverse the trust settings: set /EnableSIDHistory:No, re-enable full SID filtering, then remove the trust when the source is decommissioned.
5. Remove migration artefacts: uninstall PES, delete and destroy the key file, delete the $$$ group, remove TcpipClientSupport, disable and delete migration accounts, remove ADMT and its database from the migration server.
6. Decommission the source: demote domain controllers, clean up DNS and metadata, and archive the source directory for the retention period your records policy needs.

Detection and measurement

For event IDs and collection, see the Active Directory Security Monitoring and Event IDs Guide. Metrics that show the migration is safe:

• Objects carrying sIDHistory: count in the target, trending to zero by an agreed date.
• SID history mapping to privileged RIDs: must be zero at all times.
• Service accounts migrated with an owner: 100 percent; accounts rebuilt as gMSAs as a percentage of eligible ones.
• Source accounts still enabled after cutover: target zero after each batch's grace period.
• Days the trust has honoured SID history: against the planned window.
• Accounts excluded as stale: shows the clean-up actually happened.

Framework mapping

Common failure patterns

• SID history left forever. Projects stop when users can work, so SID history and the relaxed trust stay for years and an old privileged SID keeps working in a forest no one reviews.
• Privileged groups migrated wholesale. The source Domain Admins group is mapped to a target admin group, giving the acquired company's admins, and their compromised workstations, control of the acquirer.
• Service accounts cloned blind. A service account is migrated with its ten-year-old password and broad rights because no one knew what used it, then becomes the target's newest unmanaged credential.
• Migration tooling never removed. PES stays installed on a source DC, migration accounts stay in Domain Admins and the key file sits on a share.
• Trust built to a compromised forest. Integration starts before an assessment, so an attacker already in the acquired forest gains a path into the acquirer through the trust.
• Two live identities per person. Source accounts stay enabled after cutover and nobody monitors them, giving an attacker a quieter account to use (T1078.002 Domain Accounts).

Practitioner checklist

• Assess the source forest for compromise and privilege sprawl before creating any trust.
• Choose clone, collapse or greenfield deliberately, and write down why.
• Build an exclusion list: privileged groups, stale accounts, ownerless service accounts.
• Enable SID history on the trust only for the migration window, with selective authentication and an end date.
• Run migration accounts from privileged access workstations and disable them between runs.
• Rebuild privileged and service accounts fresh in the target, as gMSAs where possible; never migrate their password hashes.
• Alert on 4765, 4766, trust events and the PES service outside approved runs.
• Translate ACLs in replace mode, then remove sIDHistory and reverse the trust settings.
• Remove PES, the key file, the $$$ group, TcpipClientSupport and migration accounts, then decommission the source.

Standards and references

• Microsoft: ADMT Guide, Migrating and Restructuring Active Directory Domains
• Microsoft: Checklist, Performing an Interforest Migration
• Microsoft: Using DsAddSidHistory for inter-forest sIDHistory migration
• Microsoft: Configuring the Source and Target Domains for SID History Migration
• Microsoft: Enabling Migration of Passwords
• Microsoft: Netdom trust
• MITRE ATT&CK: SID-History Injection
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Active Directory Trusts and SID Filtering Guide · Identity Integration in M&A Guide · Retiring Active Directory · Windows Services and Service Account Security Guide · Identity Platform Migration