Active Directory Trust SID Filtering Selective Authentication Audit: Detection and Remediation

Active Directory Trust SID Filtering, Selective Authentication Audit Checklist

An Active Directory trust SID filtering selective authentication audit answers one question: if the domain or forest on the other end of a trust is compromised, how far can an attacker walk into yours? A trust is not a single on/off switch — it is a Trusted Domain Object (TDO) carrying several independent security attributes, and each one can silently drift away from a secure default over the life of the trust. This checklist covers the three settings that matter most, the exact commands to check them, and how to fix each finding without breaking authentication for legitimate users. It's meant to be one piece of a broader review — see Audit Active Directory Security: What to Review First and How to Prove Remediation for where trusts fit into the full scope.

Three settings do most of the work:

• SID filtering (quarantine) — blocks a compromised trusted domain from injecting forged SID history to claim privileged group membership on your side.
• Selective authentication — restricts which accounts in the trusted domain/forest may authenticate to which resources on your side, instead of trusting the whole population.
• Trust encryption — whether Kerberos traffic across the trust can still fall back to RC4, or is AES-only.

Where the Settings Actually Live

Every trust attribute lives on the TDO's trustAttributes bitmask. Per the TrustAttributes field documented for Windows Security event 4716, the bits that matter most for this audit are 0x4 (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN — SID filtering active), 0x8 (TRUST_ATTRIBUTE_FOREST_TRANSITIVE — cross-forest trust), and 0x40 (TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL — relaxes forest-trust filtering down to external-trust rules). Selective authentication and the trust's supported Kerberos encryption types are stored separately, on the msDS-SupportedEncryptionTypes attribute of the trust's interdomain trust account. None of these three settings depend on each other — a trust can have SID filtering enabled while still allowing RC4-only encryption or forest-wide authentication, so each one needs its own check.

SID Filtering: Verifying Quarantine Is Actually On

SID filtering is enabled by default on both external trusts and forest trusts — it is explicitly disabled for intra-forest (parent/child) trusts, where SID history is expected and trusted. The catalogue gap TRUST_SID_FILTERING_DISABLED fires when quarantine has been turned off on an inter-forest or external trust, which is almost always the result of a migration project that flipped it off to preserve SID history and never flipped it back on.

Checking Quarantine State

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

SIDFilteringQuarantined = $False on an external or forest trust means SID history from the other side is accepted without filtering — a compromised admin in the trusted domain can forge a SID history entry claiming Domain Admins (or Enterprise Admins) membership and walk straight in via the trust. netdom reads and sets the same attribute:

netdom trust TrustingDomain /domain:TrustedDomain /quarantine
netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

Fixing It Without Breaking a Migration

Selective Authentication: Narrowing Who Can Authenticate

Selective authentication is configured on the outgoing side of an external or forest trust and restricts authentication to only the trusted-side accounts that have been explicitly granted the Allowed to Authenticate extended right on the specific computer objects they need to reach. Without it, every authenticated user in the trusted domain or forest can attempt to authenticate to any resource on the trusting side — Kerberos will still enforce object-level ACLs, but the attack surface for credential attacks, resource enumeration, and lateral movement is dramatically larger.

The gap TRUST_EXTERNAL_NO_SELECTIVE_AUTH flags external trusts running without it — external trusts are frequently set up for a single line-of-business integration (a partner domain, an acquired subsidiary not yet merged) and left at forest-wide authentication because nobody scoped the "Allowed to Authenticate" grants during setup.

Checking Selective Authentication State

Get-ADTrust -Filter * | Select-Object Name, Direction, SelectiveAuthentication

A $False value on an external or one-way forest trust means the trust is wide open to every account on the trusted side. Compare this against the actual business need — if only three service accounts from a partner domain need to reach one file server, selective authentication plus three "Allowed to Authenticate" grants replaces "the entire partner domain can reach everything" with a named, auditable allow list.

Trust Encryption: RC4 vs AES on the Wire

The msDS-SupportedEncryptionTypes attribute on the trust's interdomain trust account determines which Kerberos encryption types are negotiated for cross-trust tickets, using the same bitmask Microsoft documents for account encryption types: 0x4 = RC4 only, 0x18 = AES128 + AES256 only, 0x1C = RC4 plus both AES strengths. A value of 0 (undefined) falls back to RC4_HMAC_MD5. For the broader picture of where RC4 fallback still creeps in outside of trusts, see Kerberos RC4 Fallback in Active Directory.

Checking the Trust's Encryption Types

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Get-ADObject $trustDN -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

• TRUST_RC4_ONLY fires when the attribute resolves to 0x4 — every service ticket crossing the trust uses RC4, the encryption type behind CVE-2022-37966 and the Kerberoasting attack class. Microsoft has stated it plans to disable RC4 as the default assumed supported encryption type for domain controllers by the end of Q2 2026, so an RC4-only trust is also a forward-compatibility problem, not just a hardening gap.
• TRUST_AES_DISABLED fires when AES bits (0x8/0x10) are absent from the attribute entirely — the trust has never been configured for AES and is relying on whatever the domain-wide default happens to resolve to.

Detection

Event Log Detection

For the full picture of which Windows Security event IDs to prioritize beyond trusts, see Active Directory Monitoring: Security Event IDs That Matter.

PowerShell Posture Checks

# One-shot posture check across every trust
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

# Force a ticket request across the trust and read the negotiated encryption type
klist get HOST/dc01.trusted.example.com

A klist result showing RC4-HMAC where you expected AES256-CTS-HMAC-SHA1-96 confirms the trust is still negotiating RC4 in practice, not just in configuration.

Remediation

Step-by-Step Hardening

1. Re-enable SID filtering on every external and forest trust that isn't mid-migration: netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes.
2. Scope selective authentication on external and one-way forest trusts: enable it on the outgoing side, then grant Allowed to Authenticate only on the specific computer objects the trusted-side accounts actually need — not the whole OU.
3. Move trusts to AES-only: set msDS-SupportedEncryptionTypes to 0x18 on the interdomain trust account, and apply the Network security: Configure encryption types allowed for Kerberos GPO to restrict to AES128/AES256 domain-wide before disabling RC4 at the trust level, to avoid breaking legacy members that still only support RC4.
4. Re-verify after the change window: re-run the Get-ADTrust check and confirm Event ID 4716 logged the expected modification, then watch 4768/4769 for a few days to confirm no unexpected authentication failures from devices that still needed RC4.

Common Failure Mode to Test For

Compliance Mapping

Trust hardening also maps to established French ANSSI Active Directory guidance (ANSSI-PA-099, section 3.2.3.1), useful if your audit needs to tie back to a named framework rather than just internal best practice: R24 ("Durcir la configuration des relations d'approbation AD sortantes extraforêt") covers re-enabling SID filtering — removing TREAT_AS_EXTERNAL and adding QUARANTINED_DOMAIN — on outgoing forest and external trusts, and R25+ ("Utiliser des relations d'approbation sortantes avec authentification sélective") covers scoping selective authentication on those same trusts. A trust failing both R24 and R25+ at once should be treated as the highest-priority finding in the audit, since it has neither access-control layer this article covers. ANSSI's guide does not publish a trust-specific recommendation for RC4/AES encryption, so treat the encryption check above as a hardening measure that stands on its own. Treat R24/R25+ as a way to communicate severity to auditors and stakeholders who already work from the ANSSI framework, not as a replacement for the underlying Get-ADTrust and msDS-SupportedEncryptionTypes checks above.

How EtcSec Detects This

EtcSec's Trusts checks read the TDO's trustAttributes bitmask and the interdomain trust account's msDS-SupportedEncryptionTypes directly, flagging TRUST_SID_FILTERING_DISABLED and TRUST_AES_DISABLED/TRUST_RC4_ONLY the same way Get-ADTrust and Get-ADObject do above, plus TRUST_EXTERNAL_NO_SELECTIVE_AUTH for external trusts missing the selective-authentication flag. Findings link back to the specific trust object and its direction, so remediation targets the exact netdom or PowerShell command needed — no manual cross-referencing of AD Domains and Trusts against a spreadsheet. If trust drift keeps recurring between audits, Recurring AD Audit Workflow covers how to catch it continuously instead of once a year.