Filtro SID Active Directory: autenticazione selettiva, rilevamento e remediation dei trust

Filtro SID Active Directory: checklist di audit dell'autenticazione selettiva nei trust

Un audit del filtro SID Active Directory e dell'autenticazione selettiva nei trust risponde a una sola domanda: se il dominio o la foresta dall'altra parte di un trust viene compromesso, quanto lontano può spingersi un attaccante nel vostro? Un trust non è un semplice interruttore on/off — è un Trusted Domain Object (TDO) che porta diversi attributi di sicurezza indipendenti, e ciascuno può allontanarsi silenziosamente da una configurazione sicura di default nel corso della vita del trust. Questa checklist copre le tre impostazioni più importanti, i comandi esatti per verificarle, e come correggere ogni anomalia senza interrompere l'autenticazione degli utenti legittimi. Fa parte di una revisione più ampia — vedi Verificare la sicurezza di Active Directory: cosa controllare per primo e come dimostrare la remediation per capire dove si collocano i trust nell'ambito completo.

Tre impostazioni fanno la maggior parte del lavoro:

• Il filtro SID (quarantena) — impedisce a un dominio trusted compromesso di iniettare una cronologia SID falsificata per rivendicare l'appartenenza a un gruppo privilegiato sul vostro lato.
• L'autenticazione selettiva — limita quali account del dominio/foresta trusted possono autenticarsi verso quali risorse sul vostro lato, invece di fidarsi dell'intera popolazione.
• La cifratura del trust — indica se il traffico Kerberos che attraversa il trust può ancora ricadere su RC4, o se è esclusivamente AES.

Dove vivono davvero queste impostazioni

Ogni attributo di trust vive nel bitmask trustAttributes del TDO. Secondo il campo TrustAttributes documentato per l'evento di sicurezza Windows 4716, i bit più importanti per questo audit sono 0x4 (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN — filtro SID attivo), 0x8 (TRUST_ATTRIBUTE_FOREST_TRANSITIVE — trust transitivo tra foreste) e 0x40 (TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL — allenta il filtro di un trust di foresta alle regole di un trust esterno). L'autenticazione selettiva e i tipi di cifratura Kerberos supportati dal trust sono memorizzati separatamente, nell'attributo msDS-SupportedEncryptionTypes dell'account trust interdominio. Nessuna di queste tre impostazioni dipende dalle altre — un trust può avere il filtro SID attivo pur consentendo una cifratura solo RC4 o un'autenticazione a livello dell'intera foresta, quindi ciascuna richiede una verifica a sé.

Filtro SID: verificare che la quarantena sia davvero attiva

Il filtro SID è attivo per default sia sui trust esterni sia sui trust di foresta — è esplicitamente disattivato per i trust intra-foresta (padre/figlio), dove la cronologia SID è attesa e considerata affidabile. L'anomalia TRUST_SID_FILTERING_DISABLED scatta quando la quarantena è stata disattivata su un trust inter-foresta o esterno, il che è quasi sempre il risultato di un progetto di migrazione che l'ha disattivata per preservare la cronologia SID e non l'ha mai riattivata.

Verificare lo stato della quarantena

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

SIDFilteringQuarantined = $False su un trust esterno o di foresta significa che la cronologia SID proveniente dall'altro lato viene accettata senza filtro — un amministratore compromesso nel dominio trusted può falsificare una voce di cronologia SID rivendicando l'appartenenza ai Domain Admins (o Enterprise Admins) ed entrare direttamente tramite il trust. netdom legge e imposta lo stesso attributo:

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

Correggerlo senza interrompere una migrazione

Autenticazione selettiva: limitare chi può autenticarsi

L'autenticazione selettiva si configura sul lato in uscita di un trust esterno o di foresta e limita l'autenticazione ai soli account del lato trusted a cui è stato esplicitamente concesso il diritto esteso Allowed to Authenticate sugli oggetti computer specifici che devono raggiungere. Senza di essa, ogni utente autenticato del dominio o della foresta trusted può tentare di autenticarsi verso qualsiasi risorsa sul lato che concede fiducia — Kerberos continuerà ad applicare le ACL a livello di oggetto, ma la superficie di attacco per attacchi alle credenziali, enumerazione delle risorse e movimento laterale è drammaticamente più ampia.

L'anomalia TRUST_EXTERNAL_NO_SELECTIVE_AUTH segnala i trust esterni che operano senza di essa — i trust esterni vengono spesso configurati per una singola integrazione di business (un dominio partner, una filiale acquisita non ancora fusa) e lasciati con autenticazione a livello dell'intera foresta perché nessuno ha delimitato le concessioni "Allowed to Authenticate" durante la configurazione.

Verificare lo stato dell'autenticazione selettiva

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

Un valore $False su un trust esterno o un trust di foresta monodirezionale significa che il trust è completamente aperto a tutti gli account del lato trusted. Confrontate questo con l'effettiva esigenza di business — se solo tre account di servizio di un dominio partner devono raggiungere un unico file server, l'autenticazione selettiva più tre concessioni "Allowed to Authenticate" sostituiscono "l'intero dominio partner può raggiungere tutto" con una allow list nominale e verificabile.

Cifratura del trust: RC4 contro AES sulla rete

L'attributo msDS-SupportedEncryptionTypes dell'account trust interdominio determina quali tipi di cifratura Kerberos vengono negoziati per i ticket che attraversano il trust, usando lo stesso bitmask documentato da Microsoft per i tipi di cifratura degli account: 0x4 = solo RC4, 0x18 = solo AES128 + AES256, 0x1C = RC4 più entrambe le robustezze AES. Un valore 0 (non definito) ricade su RC4_HMAC_MD5. Per un quadro più ampio di dove il fallback a RC4 si insinua ancora al di fuori dei trust, vedi Fallback Kerberos RC4 in Active Directory.

Verificare i tipi di cifratura del trust

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

• TRUST_RC4_ONLY scatta quando l'attributo risolve a 0x4 — ogni service ticket che attraversa il trust usa RC4, il tipo di cifratura dietro CVE-2022-37966 e la classe di attacco Kerberoasting. Microsoft ha dichiarato di voler disattivare RC4 come tipo di cifratura supportato di default sui domain controller entro la fine del Q2 2026, quindi un trust solo-RC4 è anche un problema di compatibilità futura, non solo una lacuna di hardening.
• TRUST_AES_DISABLED scatta quando i bit AES (0x8/0x10) sono completamente assenti dall'attributo — il trust non è mai stato configurato per AES e dipende da qualunque valore risolva il default a livello di dominio.

Rilevamento

Rilevamento tramite log eventi

Per il quadro completo degli Event ID di sicurezza Windows da prioritizzare oltre ai trust, vedi Monitoraggio di Active Directory: gli Event ID di sicurezza che contano.

Controlli di postura con PowerShell

# Controllo di postura in un solo passaggio su tutti i trust
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

# Forzare una richiesta di ticket sul trust e leggere il tipo di cifratura negoziato
klist get HOST/dc01.trusted.example.com

Un risultato di klist che mostra RC4-HMAC quando ci si aspettava AES256-CTS-HMAC-SHA1-96 conferma che il trust sta ancora negoziando RC4 nella pratica, non solo nella configurazione.

Remediation del filtro SID Active Directory e dell'autenticazione selettiva

Hardening passo per passo

1. Riattivare il filtro SID su ogni trust esterno e di foresta che non sia in piena migrazione: netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes.
2. Delimitare l'autenticazione selettiva sui trust esterni e di foresta monodirezionali: attivarla sul lato in uscita, poi concedere Allowed to Authenticate solo sugli oggetti computer specifici di cui gli account del lato trusted hanno effettivamente bisogno — non sull'intera OU.
3. Migrare i trust a solo AES: impostare msDS-SupportedEncryptionTypes a 0x18 sull'account trust interdominio, e applicare la GPO Network security: Configure encryption types allowed for Kerberos per limitare ad AES128/AES256 a livello di dominio prima di disattivare RC4 a livello di trust, per evitare di interrompere i membri legacy che supportano ancora solo RC4.
4. Riverificare dopo la finestra di modifica: rieseguire il controllo Get-ADTrust e confermare che l'Event ID 4716 abbia registrato la modifica attesa, poi monitorare 4768/4769 per qualche giorno per confermare l'assenza di errori di autenticazione inattesi da dispositivi che avevano ancora bisogno di RC4.

Modalità di fallimento comune da testare

Corrispondenza con la compliance

L'hardening dei trust corrisponde anche alla guida francese ANSSI sulla sicurezza di Active Directory (ANSSI-PA-099, sezione 3.2.3.1), utile se il vostro audit deve ricollegarsi a un framework riconosciuto invece che solo a buone pratiche interne: R24 ("Durcir la configuration des relations d'approbation AD sortantes extraforêt") copre la riattivazione del filtro SID — rimozione di TREAT_AS_EXTERNAL e aggiunta di QUARANTINED_DOMAIN — sui trust di foresta ed esterni in uscita, e R25+ ("Utiliser des relations d'approbation sortantes avec authentification sélective") copre la delimitazione dell'autenticazione selettiva su quegli stessi trust. Un trust che fallisce sia R24 sia R25+ contemporaneamente deve essere trattato come l'anomalia a priorità più alta dell'audit, poiché non dispone di nessuno dei due livelli di controllo degli accessi trattati in questo articolo. La guida ANSSI non pubblica una raccomandazione specifica per i trust riguardo alla cifratura RC4/AES, quindi trattate il controllo della cifratura qui sopra come una misura di hardening a sé stante. Trattate R24/R25+ come un modo per comunicare la gravità ad auditor e stakeholder che già lavorano con il framework ANSSI, non come un sostituto dei controlli sottostanti Get-ADTrust e msDS-SupportedEncryptionTypes visti sopra.

Come EtcSec rileva questo

I controlli Trusts di EtcSec leggono direttamente il bitmask trustAttributes del TDO e l'attributo msDS-SupportedEncryptionTypes dell'account trust interdominio, segnalando TRUST_SID_FILTERING_DISABLED e TRUST_AES_DISABLED/TRUST_RC4_ONLY nello stesso modo in cui lo fanno Get-ADTrust e Get-ADObject sopra, più TRUST_EXTERNAL_NO_SELECTIVE_AUTH per i trust esterni privi del flag di autenticazione selettiva. Le anomalie rimandano all'oggetto trust specifico e alla sua direzione, così che la remediation punti esattamente al comando netdom o PowerShell necessario — senza dover incrociare manualmente AD Domains and Trusts con un foglio di calcolo. Se il drift dei trust continua a ripresentarsi tra un audit e l'altro, Workflow di audit AD ricorrente spiega come rilevarlo in modo continuo invece che una volta l'anno.