SID History Attribute: The Post-Migration Escalation Path

The Trap

The sIDHistory attribute retained on user and computer objects after an ADMT (Active Directory Migration Tool) migration, with no SID filtering enforced on the trust used to carry out the move.

The Default State

The standard ADMT migration wizard ships with “migrate objects’ SIDs to target domain” enabled, which writes the source domain’s account SID into sIDHistory on the target object so existing resource ACLs keep working during coexistence. Trusts built for the migration, whether temporary forest trusts or long-lived two-way trusts, are frequently created with netdom trust and left without the /quarantine:yes flag, so SID filtering is never applied. Intra-forest domain consolidations are worse still: SID filtering only operates at a trust boundary, so a same-forest migration has no mechanism at all to constrain sIDHistory values once they are written.

The Blast Radius

When a domain controller builds the Kerberos PAC (Privilege Attribute Certificate) for authentication, it includes every SID in sIDHistory alongside current group memberships. A migrated account that shows up as a plain member of Domain Users in the target domain can still authenticate with the authorisation power of Domain Admins or Enterprise Admins from the retired source domain, because that SID never left sIDHistory. Any resource ACL still referencing the old domain’s privileged SID silently grants access. Worse, an attacker who compromises a domain controller or exploits an unfiltered trust can inject arbitrary sIDHistory values (a documented DCSync-adjacent escalation), forging membership in a privileged group that was never granted through normal delegation. Standard BloodHound sweeps and access reviews that walk group membership miss this entirely, because the escalation lives in an attribute nobody re-checks after go-live.

The Lead Mechanic Fix

Audit first: Get-ADUser -Filter {SIDHistory -like '*'} -Properties SIDHistory against every domain that has ever run a migration. Enforce SID filtering on every external and forest trust with netdom trust <TrustingDomain> /domain:<TrustedDomain> /quarantine:yes, which blocks SIDs outside the trusted domain’s namespace at the trust boundary. Intra-forest migrations get no such protection, so treat sIDHistory as a time-boxed migration artefact: clear it with Set-ADUser -Identity <user> -Clear SIDHistory or an ldifde delete once the coexistence window closes, and re-ACL any resource still referencing the legacy domain SID before the attribute is removed, so access no longer depends on it at all.