Disabling SID Filter Quarantine on a Forest Trust Reopens SIDHistory Escalation

Symptom

After a forest trust is established following an ADMT-style migration, accounts carried over with populated sIDHistory attributes lose access to resources that were never re-permissioned with their new primary SID. Helpdesk tickets describe access-denied errors on file shares and applications that worked before migration, even though group membership appears correct.

False Assumption

The administrator assumes that disabling SID filtering, commonly exposed as “quarantine” on the trust object, is a narrow compatibility switch that restores access only for the specific migrated accounts experiencing problems. In practice, quarantine is a single trust-wide boolean. It cannot be scoped to particular accounts, particular SIDHistory values, or particular resources. Turning it off removes the control for every principal that authenticates across that trust, not only the ones the administrator intended to help.

Root Cause

SID filtering (quarantine) is documented Windows Server Active Directory Domain Services behaviour that strips or ignores SIDHistory values presented in an authentication request that crosses an external or forest trust boundary. Its purpose is to stop a principal on the trusted side of the trust from presenting a SIDHistory value that matches a privileged SID on the trusting side (for example, a Domain Admins-equivalent SID), which would otherwise grant elevated access purely because the trust exists. When an administrator runs the trust-level command to disable quarantine as a blanket fix for migrated-account access, the trust boundary stops filtering SIDHistory for everyone who authenticates across it, including any principal that later acquires a SIDHistory value matching a privileged SID through further migrations, replication tampering, or compromise of the trusted domain.

Impact

Any identity able to obtain a SIDHistory value referencing a privileged SID in the trusting domain can escalate privilege across the trust once quarantine is disabled, independent of the original migrated accounts the change was meant to support. In environments where the trust remains active long after the migration project ends, this converts a temporary compatibility trust into a standing cross-forest privilege escalation path. The risk is highest where the trust direction allows the trusted domain’s principals to authenticate into the trusting domain and where administrative or service accounts still carry historical SIDHistory entries.

Diagnosis

Confirm the current filtering state on every trust before assuming intent. In an isolated test AD instance or a change-controlled production session with appropriate rights, enumerate trusts and their SID filtering state:

Get-ADTrust -Filter * | Select-Object Name,Direction,SIDFilteringQuarantined,SIDFilteringForestAware

A trust returning SIDFilteringQuarantined : False on a production or long-lived trust, where no active migration is in progress, is the indicator of this misconfiguration. Cross-check whether the trust was originally created as a time-boxed migration trust that was never revisited after the migration project closed; that history is an environmental assumption worth confirming with change records rather than inferring from the trust object alone.

Correction

Re-enabling quarantine restores the trust-boundary control; it does not, by itself, fix the resource access that prompted the original change, so both steps are required. First, re-enable filtering on the affected trust from an account holding the required trust-management privilege:

Set-ADTrust -Identity "trusted.forest.example" -SIDFilteringQuarantined $true

Second, address the underlying access failure at the resource layer instead of the trust layer: identify resources whose access control entries still depend on a migrated account’s SIDHistory-derived SID, and re-permission those entries using the account’s current primary domain SID. This is typically a manual or tooling-assisted ACL remediation exercise scoped to the migrated accounts and resources actually affected, not a trust-wide setting.

Validation

Validation must confirm both that the security control is restored and that legitimate access has not regressed. Re-run the diagnostic command and confirm the value:

Get-ADTrust -Filter * | Select-Object Name,SIDFilteringQuarantined

Expect SIDFilteringQuarantined : True for the corrected trust. Then test authentication and resource access for a representative sample of the previously migrated accounts, and review authentication logs for unexpected Kerberos failures rather than assuming success from the cmdlet output alone:

Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4768 or EventID=4769)]]" -MaxEvents 50

A pass condition is a correctly filtered trust with no unexpected access failures for accounts whose resource permissions were remediated; any account that still fails access has an outstanding ACL remediation gap, not a reason to disable quarantine again.

Rollback

If re-enabling quarantine breaks access for accounts that were not yet remediated, the safe recovery path is to fix the resource permissions, not to disable the trust control again. Where service continuity cannot wait for full ACL remediation, treat any temporary reversal as a documented, time-boxed exception: record the exact scope and time the trust was returned to an unfiltered state, monitor authentication logs for that window, and re-enable quarantine as soon as the specific resources are remediated. Confirm the trust’s final state with Get-ADTrust after any change and record it in the trust’s change history so the setting is never left unfiltered by default.

Prevention

Treat migration-era trusts as temporary infrastructure with an explicit decommission date, and review any trust with SID filtering disabled during routine Active Directory security reviews rather than only at migration time. When migrated-account access breaks after a trust is created, default to remediating resource ACLs with the account’s primary SID first; disabling quarantine trust-wide should require a documented, time-boxed exception with a named owner, not be treated as the first-line fix. Because exact cmdlet parameters and default behaviour can vary by Windows Server build, confirm current Microsoft Active Directory Domain Services documentation for the specific build in use before relying on any of the syntax above in production.