Forest trust SID filtering vs SID history — are these the same setting or two different things?

Question

Forest trust SID filtering vs SID history — are these the same setting or two different things?

Vishal Kumar 125

Hello,
Working through an AD security finding in an isolated lab and want a sanity check on my understanding before I take this to a client.

The finding: "Domain trust to a third-party domain without quarantine" (ANSSI vuln1_trusts_domain_notfiltered). Description says it looks for outbound forest trusts where the Quarantine flag is false, meaning the trusted domain isn't subject to SID filtering.

What I did in the lab:

Built two forests, forestA.local and forestB.local, and created an outbound forest trust from A (B trusts A, so A's users can be authorized in B).

Scanned it — passed clean. Trust attributes read:

Direction               : Outbound
ForestTransitive        : True
SIDFilteringForestAware : False
SIDFilteringQuarantined : False

I'd expected SIDFilteringQuarantined : False to fire the finding, but it didn't. My read is that quarantine isn't the active control on a forest trust, so False there is the normal secure default. Is that right?

Then I ran:

netdom trust forestA.local /domain:forestB.local /EnableSIDHistory:Yes

Re-scanned — finding fired. Trust attributes now showed 72 [TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL, TRUST_ATTRIBUTE_FOREST_TRANSITIVE]. Quarantine never changed; only SID history did.

Where I'm confused:

Is "enabling SID history" and "disabling SID filtering" the same change described two ways, or are they genuinely separate controls? My current understanding is that on a forest trust there's no independent filtering switch — allowing SID history is how filtering gets relaxed. Correct?

Am I right that the switch differs by trust type? Forest trust → /EnableSIDHistory, external trust → /Quarantine. Same underlying protection, different lever depending on type.

The scanner's result line says "Quarantine is disabled or SID history is enabled" — so two independent trigger conditions, either one alone fires it. Does that match how you'd read it?

Why it matters: I need to phrase this correctly in a client report. My current wording is:

"The outbound forest trust is not enforcing SID filtering because SID history is enabled across the trust. Remediation is to disable SID history, which restores filtering."

Does that hold up, or am I conflating things?

Also — practical question — has anyone hit a case where disabling SID history broke legitimate cross-forest access? Trying to work out what to ask a client before remediating, since I assume an in-flight migration is the one genuine reason it'd be on.

0 comments

2 answers

Your answer

Answer 1

Yep - your overall interpretation is correct, but I would tighten the terminology.

For a forest trust, SIDFilteringQuarantined : False by itself does not mean that SID filtering is disabled. The quarantine mechanism represented by TRUST_ATTRIBUTE_QUARANTINED_DOMAIN applies to external trusts. Forest trusts have a different mechanism for handling SID history, which is why your initial forest trust can show SIDFilteringQuarantined : False and still pass the ANSSI check.

/EnableSIDHistory:Yes is the important change in your test. It permits SID history to be used across the forest trust and, in security terms, relaxes the SID-filtering protection that would otherwise prevent foreign SIDs from being carried across the trust. It is therefore reasonable to describe it as enabling SIDHistory across the forest trust, rather than literally saying that it toggles a separate "SID filtering" switch.

So, yes, the controls differ by trust type. For an external trust, quarantine/SID filtering is controlled through the quarantine setting, such as /Quarantine:Yes. For a forest trust, the relevant control is whether SID history is enabled, such as /EnableSIDHistory:Yes. They protect against the same general class of SID-history/SID injection abuse, but they are not literally the same trust attribute.

The wording, "Quarantine is disabled or SID history is enabled," is consistent with that model: it has two independent conditions that can make the trust fail the security check. For an external trust, the quarantine condition is relevant - for a forest trust, the SID-history condition is the relevant one.

I would change your client wording slightly. Saying "the outbound forest trust is not enforcing SID filtering because SID history is enabled" is understandable, but technically it implies there is a conventional SID-filtering flag that has simply been turned off. A more precise finding would be: "SID history is enabled across the outbound forest trust, allowing SID history to be honored across the trust and thereby weakening the SID-filtering protection against unauthorized SID injection. Disable SID history unless it is required for a documented migration or interoperability scenario."

And yep - legitimate cross-forest migrations are the main thing to investigate before disabling it. SID history can be used during migrations so users/groups retain access to resources in the source forest after their accounts are migrated. If the client has an active migration, legacy cross-forest authorization, or an application specifically depending on SID history, disabling it can break access. The key question is not simply "Do you use a forest trust?" but "Is SID history currently being used across this trust, and is there a documented business requirement for it?"

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 2

They are related, but not the same setting in all cases.

For external trusts, the control called quarantine is the SID filtering control. Microsoft states that SID Filtering should be applied only to external trusts, not to trusts within the same forest. In MIM PAM guidance, the netdom trust ... /quarantine:no command is paired with enabling SID history, and the output explicitly says this means SID filtering is not enabled for this trust.

For forest trusts, the relevant lever in the provided material is SID history enablement rather than quarantine. The PAM guidance for forest-to-forest trust uses:

netdom trust contoso.local /quarantine:no /domain priv.contoso.local
netdom trust /enablesidhistory:yes /domain priv.contoso.local

and treats these as separate commands with separate effects. That supports the conclusion that quarantine and EnableSIDHistory are distinct trust settings, even though both affect whether SIDs from the other side are accepted.

So the safest interpretation is:

Not identical settings
Same security area: both influence SID acceptance/filtering behavior across a trust
Trust type matters: quarantine is the explicit SID filtering control for external trusts; SID history enablement is the relevant control called out for cross-forest migration/trust scenarios

The scanner wording, "Quarantine is disabled or SID history is enabled", is consistent with that reading. It describes two separate trigger conditions that can each weaken SID-based protections.

The statement "allowing SID history is how filtering gets relaxed" is directionally correct for a forest-trust discussion, but it is more precise to say:

Enabling SID history across a forest trust relaxes SID-based protection on that trust; on external trusts, the corresponding control is quarantine/SID filtering.

That avoids implying the two flags are literally the same setting.

A stronger client-report wording would be:

The outbound forest trust permits SID history across the trust. This weakens SID-based trust filtering protections and can allow SIDs from the trusted forest to be honored during authorization. If SID history is not required for an active migration scenario, disable SID history on the trust.

On operational impact: yes, disabling SID history can break legitimate access when SIDHistory is being used for migration. Microsoft documents SID History as supporting migration scenarios so users retain access after moving between domains or forests. Microsoft also notes that SID Filtering prevents SIDHistory from working in quarantined domains.

That means the key client questions before remediation are:

Is there an active or incomplete inter-forest migration?
Are migrated users still relying on SIDHistory to access legacy resources?
Are any accounts carrying historical SIDs specifically to preserve access during coexistence?

If the answer to those is no, disabling SID history is the cleaner remediation. If yes, remediation should be coordinated with the migration plan because access to legacy resources may fail.

Also note the security reason for the finding: Defender for Identity states that if a forest trust exists without SID Filtering enabled, it is possible to inject a SID from another forest and have it added to the user token for access evaluation.

References: