Windows 2000 Cross-Domain Migration with ADMT

The Active Directory Migration Tool (ADMT) in Microsoft Windows 2000 streamlines the process of migrating objects—such as user accounts, global groups, and computer accounts—across domain boundaries. This article details the underlying architecture, prerequisites, and step-by-step technical mechanisms Windows 2000 utilizes to perform both intra-forest and inter-forest cross-domain object migrations using ADMT, with a specific focus on security context preservation and the sIDHistory attribute.

Migration Types: Intra-Forest vs. Inter-Forest

Cross-domain migrations with ADMT operate in one of two modes, each handled differently by the Active Directory directory service:

  • Intra-Forest Move: Objects moving between domains in the same forest represent a true move operation. ADMT leverages LDAP API calls (specifically MoveObject or ModifyDN) to transfer the object. The target domain assigns a new relative identifier (RID) and security identifier (SID), while the object retains its original globally unique identifier (GUID).
  • Inter-Forest Clone: Objects moving between distinct forests represent a clone-and-state migration. Because forests do not share a common directory schema or global catalog, the object cannot be moved atomically. ADMT reads the source object's properties, creates an identical new object in the target domain with a new GUID and SID, and optionally disables the source account.

Prerequisites for Cross-Domain Migration

Before Windows 2000 and ADMT can process an object migration, several environment requirements must be satisfied:

  1. Trust Relationship: A working trust must exist between the source and target domains (a two-way trust or a one-way trust where the target trusts the source).
  2. Administrative Privileges: The operator must hold Domain Admin privileges in the target domain and local administrator rights on the source domain controllers.
  3. Auditing Configuration: Success and failure auditing for account management must be enabled on both the source and target domains to allow security identifier manipulation.
  4. Source Auditing Group: For inter-forest SID history migration, a local group named <SourceNetBIOSDomain>$$$ must be created in the source domain's built-in container. This allows the system to verify authorization to read and copy security IDs.
  5. RPC and Name Resolution: Unrestricted Remote Procedure Call (RPC) connectivity, NetBIOS name resolution, and DNS integration between the migration host, source domain controllers, and target domain controllers must be operational.

The Technical Migration Process

When a migration task is initiated in ADMT, Windows 2000 executes the transition through the following sequence:

1. Connection and Schema Verification

ADMT connects to the source Domain Controller (DC) and target DC via LDAP and RPC. It binds to the directory services to compare attribute schemas, ensuring the target domain supports all attributes designated for migration.

2. Account Information Extraction

ADMT queries the source DC to extract object attributes, including the user principal name (UPN), Security Account Manager (SAM) account name, group memberships, and user profile paths. Certain system-managed attributes (such as whenCreated, objectGUID, and memberOf) are excluded from direct copying.

3. Object Creation in the Target Domain

The target DC instantiates a new Active Directory object in the designated Organizational Unit (OU). The target domain's RID Master allocates a new RID, which combines with the target domain's base SID to generate a unique SID for the new object.

4. Preservation of Access via sIDHistory

To prevent the migrated user or group from losing access to legacy network resources, ADMT injects the source object's original SID into the target object’s sIDHistory attribute.

Windows 2000 restricts direct writes to the sIDHistory attribute via standard LDAP modifications. ADMT circumvents this restriction using an authenticated RPC API call directly against the target domain's Primary Domain Controller (PDC) emulator. The PDC emulator validates the existence of the source $$$ group, checks audit logs, confirms caller credentials, and appends the old SID into the target object’s multi-valued sIDHistory attribute. When the migrated user subsequently logs on, the Kerberos token-generation process includes all SIDs contained within sIDHistory, granting seamless access to legacy resources.

5. Password Migration Handling

In standard Windows 2000 ADMT environments, user passwords cannot be read from the source domain due to one-way hash encryption. ADMT handles passwords by either assigning a randomly generated password saved to a migration report, setting a standardized default password requiring change at next logon, or integrating with a Password Export Server (PES) service to migrate the existing password hashes.

6. Post-Migration State Adjustment

Once the object is successfully committed to the target Active Directory database:

  • In inter-forest migrations, the source DC marks the original account as disabled (if selected in migration settings) to avoid dual-identity conflicts.
  • In intra-forest migrations, the original object record is purged from the source partition, and the updated metadata replicates across the forest via directory replication agents (DRAs).