SID history migration, explained without the folklore.
SID history is the mechanism that lets a migrated account keep opening the files, shares, and applications permissioned to its old identity. It is also one of the most misunderstood — and most security-sensitive — parts of a cross-forest Active Directory migration.
How it actually works.
Every user and group has a SID unique to its domain. ACLs on files, shares, mailboxes, and applications reference those SIDs — not names. When an account is migrated to a new forest it gets a new SID, and every existing ACL entry pointing at the old SID stops matching.
- The old SID is written to the sIDHistory attribute of the new account during migration
- At sign-in, the access token includes the primary SID plus every SID in sIDHistory
- Resources permissioned to the old SID authorize the token exactly as before — no ACL change needed yet
- Group SID history matters as much as user SID history: most resource access flows through group ACL entries
- The effect is transitional by design; the end state is resources re-permissioned to new SIDs and SID history removed
What it requires — and what can break it.
Writing sIDHistory is a privileged, audited directory operation with real preconditions. These are the items that decide feasibility during assessment.
| Requirement | Detail | Failure mode if ignored |
|---|---|---|
| Trust between forests | A working trust with name resolution in both directions for the migration window. | Migration operations fail or authorize inconsistently. |
| SID filtering decision | SID filtering on the trust strips foreign SIDs from tokens and must be deliberately relaxed for SID history to work across the trust during coexistence. | SID history is written correctly but access still fails — the most common "it doesn't work" report. |
| Elevated rights and auditing | Writing sIDHistory requires high-privilege credentials and enabled account-management auditing in both domains. | Operations blocked, or security review rejects the approach after the fact. |
| Security approval | Relaxed SID filtering weakens a control against SID injection; it needs a documented, time-boxed exception. | Emergency rollback of the trust configuration mid-migration. |
| Token size headroom | Each historical SID enlarges the Kerberos token; deeply nested groups plus SID history can exceed size limits. | Intermittent authentication failures that look like random application bugs. |
SID history versus ACL restamping.
The alternative to carrying old SIDs is changing the resources: re-ACL file servers and shares so entries reference the new SIDs. Most real programs combine both.
- SID history buys coexistence time with no resource changes, but requires trust and security exceptions, and must be cleaned up before decommission
- ACL restamping produces the clean end state directly, but requires every resource to be reachable, inventoried, and re-permissioned — a program of its own on large estates
- A common pattern: SID history for the migration window, restamping as a parallel workstream, SID history removal as the decommission gate
- Either path needs validation against representative file shares and applications — not just a successful job status
Common questions.
Is SID history required for every AD migration?
No. SID history is a bridge for resource access during coexistence. If resources are re-permissioned (ACLs restamped to the new SIDs) before or during the migration, or the environment is small enough to cut over in one window, you may not need it. Many programs use SID history during waves and remove it at decommission.
Why does SID history sometimes not work across a trust?
SID filtering, which is enabled by default on newer trusts, strips foreign SIDs from the access token. For SID history to function across a forest trust during migration, SID filtering must be deliberately relaxed for that trust — a documented security decision, since it also weakens a protection against SID injection.
How does BridgeAD handle SID history and ACL restamping?
BridgeAD includes SID mapping, SID-history, and ACL restamping orchestration workflows. They are executed as controlled-pilot capabilities because they require elevated rights, security approval, reachable resources, and validation against representative file and application access before scaling to production waves.
Find out whether you need SID history at all.
A readiness assessment maps your SID dependencies, trust posture, and re-permissioning workload — so the SID history decision is made from evidence, not habit.