Come configurare e proteggere le relazioni di trust Active Directory

Cosa sono le relazioni di trust di Active Directory

Una relazione di trust di Active Directory permette a un controller di dominio di un dominio di garantire l'identità di un account autenticato in un dominio o foresta diversi. Internamente, ogni trust è memorizzata come un oggetto TDO (Trusted Domain Object) che registra il nome del dominio trustato, la direzione, la transitività e un segreto condiviso — la password della trust — usato per proteggere il traffico di autenticazione che la attraversa. Le relazioni di trust di Active Directory sono ciò che rende utilizzabile una foresta multi-dominio: senza di esse, ogni dominio sarebbe un'isola di autenticazione isolata, senza alcun modo di fare riferimento a utenti o gruppi provenienti da altrove.

Una trust da sola non concede alcun accesso. Estende solo il percorso di autenticazione — ciò che l'account richiedente può effettivamente raggiungere dall'altra parte resta comunque governato dalle ACL, dall'appartenenza ai gruppi e dalle impostazioni di delega. Detto questo, una trust configurata male amplia il raggio d'impatto di una compromissione su entrambi i lati, motivo per cui la configurazione delle trust merita la stessa disciplina di qualsiasi altra modifica Tier 0.

Tipi di trust e transitività

Non tutte le trust si comportano allo stesso modo. Due proprietà determinano quanto si estende realmente una trust: la direzione (quale lato può autenticare i propri utenti verso l'altro) e la transitività (se la trust si estende implicitamente ai domini di cui il lato trustato stesso si fida).

Due conseguenze contano ai fini dell'hardening:

• Le catene di transitività. Una trust di foresta transitiva non si ferma alla radice della foresta — si estende a ogni dominio all'interno di quella foresta. Fidarsi di una foresta significa fidarsi di ogni amministratore di dominio che contiene, non solo del team che ha richiesto l'integrazione.
• La direzione limita l'esposizione. Una trust unidirezionale in cui il dominio A si fida del dominio B consente agli utenti di B di autenticarsi in A, ma non il contrario. Dove il bisogno di business è unidirezionale, configurare una trust bidirezionale "per sicurezza" aggiunge solo un percorso di autenticazione che nessuno ha richiesto. TRUST_BIDIRECTIONAL nel catalogo EtcSec segnala ogni trust bidirezionale esterna, di foresta o tra alberi (le trust padre-figlio sono escluse, poiché sono bidirezionali per progettazione) — un segnale di configurazione da rivedere, non una certezza che il traffico fluisca solo in un senso nella pratica.

Come configurare una trust sicura passo dopo passo

I passaggi seguenti si concentrano sulle trust esterne e di foresta — i casi che richiedono un hardening deliberato. Le trust padre-figlio e di radice dell'albero vengono create automaticamente dal processo di promozione del dominio e della foresta ed ereditano le impostazioni predefinite a livello di foresta; il filtro SID non si applica a esse per progettazione, perché la cronologia SID tra domini della stessa foresta è prevista.

Passaggio 1 — Pianificare la trust prima di crearla

Annotate, prima di aprire qualsiasi console: quale lato avvia l'autenticazione, se deve essere unidirezionale o bidirezionale, quali risorse deve realmente raggiungere il lato trustato, chi possiede la relazione e una data di revisione. Una trust senza proprietario e senza data di revisione è quella che sarà ancora aperta cinque anni dopo la fine del progetto che l'aveva richiesta.

Passaggio 2 — Creare la trust

Create la trust dalla console Domini e trust di Active Directory (procedura guidata Nuova trust), oppure in modo non interattivo con netdom:

netdom trust TrustingDomain /domain:TrustedDomain /add /twoway /userD:AdminAccount /passwordD:*

Rimuovete /twoway per una trust unidirezionale — fate corrispondere il comando a ciò che il Passaggio 1 richiede realmente, non a ciò che si clicca più in fretta.

Passaggio 3 — Limitare la crittografia della trust ad AES

Le nuove trust non devono mai essere lasciate sulla crittografia predefinita. Controllate l'attributo msDS-SupportedEncryptionTypes dell'account trust interdominio e impostatelo su solo AES (0x18) non appena ogni sistema che si autentica attraverso la trust supporta AES:

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Set-ADObject $trustDN -Replace @{'msDS-SupportedEncryptionTypes' = 24}

Un attributo non definito non è nemmeno un valore predefinito sicuro da presumere in un senso o nell'altro — la documentazione Microsoft stessa indica che AES è supportato per impostazione predefinita su controller di dominio, controller di dominio in sola lettura e trust solo una volta che il controller di dominio di distribuzione è stato aggiornato per le modifiche Kerberos RC4 del 2022, e che una trust datata o mai toccata può ancora negoziare RC4. TRUST_AES_DISABLED scatta ogni volta che l'attributo non segnala il supporto AES, incluso quando è semplicemente non impostato. TRUST_RC4_ONLY è più ristretto: scatta solo quando la trust segnala esplicitamente il supporto RC4 senza AES, quindi un attributo semplicemente non definito non lo attiverà.

Passaggio 4 — Abilitare il filtro SID (quarantena)

Il filtro SID è abilitato per impostazione predefinita per le nuove trust esterne e di foresta, ma viene regolarmente disattivato durante le migrazioni che dipendono da sIDHistory e poi non viene mai riattivato. Confermatelo esplicitamente:

netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

TRUST_SID_FILTERING_DISABLED segnala qualsiasi trust esterna o di foresta in cui questo è disattivato. Non attivatelo/disattivatelo alla cieca — se una migrazione in corso dipende dalla cronologia SID per preservare l'accesso, la quarantena interromperà quell'accesso fino al completamento della migrazione.

Passaggio 5 — Delimitare l'autenticazione selettiva

L'autenticazione selettiva trasforma "qualsiasi utente autenticato sul lato trustato può tentare di raggiungere qualsiasi cosa su questo lato" in una lista di autorizzazione nominale. Abilitatela sul lato in uscita della trust, quindi concedete il diritto esteso Consentito ad autenticare solo sugli oggetti computer specifici che gli account del lato trustato devono effettivamente raggiungere:

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

TRUST_EXTERNAL_NO_SELECTIVE_AUTH scatta quando una trust esterna non ha alcuna autenticazione selettiva configurata — la lacuna più comune sulle trust create per un'integrazione una tantum con un partner.

Passaggio 6 — Convalidare la trust

Confermate che la trust si comporti come previsto dal Passaggio 1 prima di considerare la modifica conclusa:

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

Quindi forzate un vero tentativo di autenticazione attraverso la trust e rileggete il tipo di crittografia negoziato con klist. Lo stato di configurazione e ciò che viene effettivamente negoziato sulla rete possono divergere se una GPO a valle o un membro legacy sovrascrive l'impostazione propria della trust.

Rilevamento

La creazione e la modifica delle trust sono eventi registrati, non modifiche silenziose — se la deriva delle trust emerge solo in un audit periodico invece che tramite un avviso, il problema è nella pipeline di logging, non nella visibilità.

Un singolo evento prova molto poco da solo — un 4716 che disattiva SidFilteringEnabled è di routine durante una migrazione pianificata e allarmante in qualsiasi altro contesto. Generate un avviso sull'evento, quindi confrontatelo con il ticket di modifica.

Remediation e checklist di hardening

1. Inventariate ogni trust con Get-ADTrust -Filter * e registrate un proprietario, una giustificazione di business e una data di revisione per ciascuna.
2. Fate corrispondere la direzione al bisogno reale — non mantenete una trust bidirezionale dove l'autenticazione fluisce sempre in un solo senso.
3. Abilitate il filtro SID su ogni trust esterna e di foresta che non sia attivamente in migrazione.
4. Delimitate l'autenticazione selettiva ai sistemi specifici di cui il lato trustato ha bisogno, non all'intero dominio.
5. Passate a una crittografia solo AES non appena ogni sistema che si autentica la supporta.
6. Rimuovete le trust senza proprietario o bisogno di business attuale invece di lasciarle "documentate" indefinitamente.

Per la checklist completa con PowerShell per ogni controllo e la mappatura di conformità, vedere audit del filtro SID e dell'autenticazione selettiva delle trust di Active Directory. Per la narrazione dell'attacco contro cui questi controlli difendono, vedere attacchi alle trust AD: dal dominio figlio alla radice della foresta.

Ciclo di vita delle trust: bidirezionali, transitive e inattive

Le trust sono facili da creare e facili da dimenticare. Tre risultati del catalogo colpiscono esattamente questa lacuna di ciclo di vita:

• TRUST_BIDIRECTIONAL — segnala ogni trust bidirezionale al di fuori delle padre-figlio, per configurazione, indipendentemente dall'uso osservato. Se il bisogno di business è unidirezionale, restringerla a un solo senso rimuove un percorso di autenticazione senza perdita di funzionalità.
• TRUST_FOREST_TRANSITIVE — una trust di foresta eredita ogni dominio all'interno della foresta trustata, non solo il dominio che ha richiesto l'integrazione. Prima di approvare una trust di foresta, rivedete l'elenco dei domini della foresta trustata e la sua igiene amministrativa, non solo la risorsa di cui ha bisogno il richiedente.
• TRUST_INACTIVE — una trust la cui password interdominio non ruota da oltre 180 giorni. Windows ruota automaticamente la password di una trust attiva circa ogni 30 giorni, quindi un pwdLastSet obsoleto è un indicatore di una trust abbandonata che nessuno mantiene, più che una misura diretta del traffico di autenticazione. Una trust inattiva che nessuno usa resta comunque un percorso di autenticazione attivo che nessuno controlla. Se il bisogno di business è terminato, rimuovete la trust tramite il normale processo di modifica invece di lasciarla "nel dubbio".

Nessuno di questi tre richiede una compromissione per contare — sono problemi di configurazione e igiene di ciclo di vita che riducono la superficie di attacco prima di un incidente, non dopo.

Come EtcSec rileva questo

EtcSec legge direttamente il bitmask trustAttributes di ogni oggetto TDO (Trusted Domain Object) e l'attributo msDS-SupportedEncryptionTypes dell'account trust interdominio — le stesse proprietà che Get-ADTrust e Get-ADObject espongono sopra. Segnala TRUST_SID_FILTERING_DISABLED, TRUST_EXTERNAL_NO_SELECTIVE_AUTH, TRUST_BIDIRECTIONAL, TRUST_FOREST_TRANSITIVE, TRUST_INACTIVE, TRUST_RC4_ONLY e TRUST_AES_DISABLED su ogni trust dell'ambiente, con i risultati collegati all'oggetto trust specifico affinché la remediation punti esattamente al comando necessario.

Approfondimenti

Per la narrazione dell'attacco contro cui questi controlli difendono, vedere attacchi alle trust AD: dal dominio figlio alla radice della foresta. Per la checklist di audit approfondita su filtro SID, autenticazione selettiva e crittografia, vedere audit del filtro SID e dell'autenticazione selettiva delle trust di Active Directory. La rotazione della password della trust è trattata in rotazione della password krbtgt, dell'account trust e della password macchina del controller di dominio, e il rischio di delega che spesso attraversa un confine di trust è trattato in attacchi di delega Kerberos da non vincolata a RBCD. Per sapere dove si colloca la revisione delle trust in un audit completo dell'ambiente, vedere audit di sicurezza di Active Directory: cosa verificare per primo e come dimostrare la remediation.

Riferimenti principali

• Forest Design Models
• netdom trust command
• MS-PAC: SID Filtering and Claims Transformation
• Event ID 4706 — A new trust was created
• Event ID 4716 — Trusted domain information was modified
• Event ID 4769 — A Kerberos service ticket was requested
• Detecting and remediating RC4 usage for Kerberos
• Securing domain controllers against attack