Rotazione password krbtgt, account trust, controller di dominio: password macchina e i tre segreti di Active Directory che non si ruotano mai da soli

Active Directory sembra un sistema che mantiene da solo i propri segreti sempre aggiornati. I computer aggiunti al dominio cambiano la propria password secondo una pianificazione, i trust si rinnovano in background e nessuno apre mai un ticket per questo. È esattamente per questa impressione che l'igiene di rotazione password krbtgt, account trust, controller di dominio (e della sua password macchina) è il punto cieco più silenzioso nella maggior parte dei parchi AD: uno di questi tre segreti non ha alcuna rotazione automatica, e gli altri due si ruotano solo finché nulla si rompe in silenzio. Questo articolo spiega cosa fa davvero ciascun meccanismo, come verificare tutti e tre in pochi minuti e come correggerli senza causare un'interruzione dell'autenticazione a livello di dominio.

Rotazione password krbtgt, account trust, controller di dominio: chi ruota cosa

La trappola nasce da un'inferenza perfettamente ragionevole. La documentazione delle policy Microsoft afferma che nei domini basati su Active Directory ogni dispositivo dispone di un account e di una password e che, per impostazione predefinita, i membri del dominio inviano una richiesta di cambio password ogni 30 giorni (Domain member: Maximum machine account password age). Le macchine si mantengono davvero da sole, quindi gli amministratori generalizzano: pensano che la directory gestisca da sé tutti i propri segreti.

Due dei tre segreti sopra elencati sono effettivamente automatici. Ma qui "automatico" significa automatico finché tutto è in salute, e il segreto più prezioso dell'intero dominio non è mai stato automatico fin dall'inizio.

krbtgt: la password che Active Directory non cambia mai per te

L'account krbtgt è il punto in cui risiede il materiale chiave Kerberos del dominio: ogni TGT del dominio viene cifrato e firmato con la sua chiave. Microsoft descrive l'account esattamente in questi termini: supporta l'archiviazione delle chiavi in tutti i Key Distribution Center (KDC) Kerberos, e per rinnovare le chiavi Kerberos usate per cifrare i TGT è necessario cambiare periodicamente la password dell'account krbtgt (Accounts security posture assessment). Nulla, nella directory, esegue quel cambio al posto tuo: non esiste alcun timer di Netlogon né alcuna impostazione di policy dietro le quinte, solo un amministratore che lancia il reset a mano.

Questo è l'intero problema. Senza rotazione, il raggio d'azione di una singola copia storica del database dell'account non si riduce mai, e Microsoft ne descrive la conseguenza in modo esplicito: se la password dell'account KRBTGT viene compromessa, un attaccante può usarne l'hash per generare ticket di autenticazione Kerberos validi, il che gli permette di eseguire attacchi Golden Ticket e ottenere accesso a qualsiasi risorsa del dominio AD; poiché Kerberos si affida alla password KRBTGT per firmare tutti i ticket, monitorarla da vicino e cambiarla regolarmente è essenziale per mitigare il rischio di questo tipo di attacchi. La stessa baseline Microsoft dà un numero concreto a regolarmente: Defender for Identity include una raccomandazione chiamata Change password for krbtgt account, che elenca qualsiasi account krbtgt dell'ambiente la cui password risulta impostata da oltre 180 giorni. Quali algoritmi usino quelle chiavi è l'altra metà della storia, trattata nella nostra guida al fallback Kerberos RC4.

Cosa faccia un attaccante con quella chiave è trattato in dettaglio nella nostra guida all'attacco Golden Ticket — questo articolo si concentra sull'igiene di rotazione che fa scadere il ticket forgiato invece di lasciarlo vivere per sempre.

Password dei trust: automatica solo da un lato

I trust interdominio si ruotano davvero, e lo fanno senza che nessuno lo chieda. La documentazione Microsoft sugli interni dei trust descrive il meccanismo: i due domini di una relazione di trust condividono una password, memorizzata nell'oggetto TDO in Active Directory, e come parte del processo di manutenzione dell'account, ogni trenta giorni, il domain controller del dominio trusting cambia la password memorizzata nel TDO (How Domain and Forest Trusts Work — un documento archiviato di Windows Server 2003, tuttora la descrizione pubblica più dettagliata del processo).

Da quel documento, tre dettagli contano dal punto di vista operativo:

• Solo un lato guida il processo. Un domain controller del dominio trusted non avvia mai il cambio password; è sempre il PDC emulator del dominio trusting a farlo.
• La vecchia password viene conservata di proposito. Se l'autenticazione con la nuova password fallisce, il domain controller del dominio trusting prova ad autenticarsi con la vecchia password e, se riesce, riprende il processo di cambio password entro 15 minuti — motivo per cui sia il valore vecchio sia quello nuovo restano presenti nel TDO.
• La replica ha una scadenza rigida. Gli aggiornamenti della password di trust devono replicarsi verso i domain controller di entrambi i lati del trust entro 30 giorni. Se la password di trust viene cambiata dopo 30 giorni e un domain controller possiede a quel punto solo la password N-2, non può usare il trust dal lato trusting e non può creare un canale sicuro sul lato trusted.

Il segreto in sé non è un normale attributo di tipo password: Microsoft osserva che i segreti di trust sono rappresentati da attributi speciali sugli account di trust interdominio, trustAuthIncoming sul lato trusted e trustAuthOutgoing sul lato trusting, e che vengono mantenuti dal domain controller che detiene il ruolo FSMO (Flexible Single Master Operation) di PDC emulator nel dominio trusting (UserAccountControl property flags).

Ciò che puoi invece leggere è l'account di trust interdominio associato al TDO. Secondo MS-ADTS, i trust il cui trustDirection è in ingresso o bidirezionale hanno un account utente associato nel container utenti predefinito, e i due oggetti sono collegati tramite il nome NetBIOS del partner: il flatName del TDO corrisponde al sAMAccountName dell'account meno il $ finale. Il checkpoint ANSSI Trust account passwords unchanged for more than a year legge esattamente il pwdLastSet di quell'account, e il suo verdetto merita di essere riportato: un valore non aggiornato può essere indicativo di relazioni di trust eliminate i cui account di trust corrispondenti sono ancora presenti, e laddove il trust sia ancora attivo, occorre indagare la causa della mancata rotazione automatica.

Se stai auditando i trust più in generale, abbina questo articolo alle nostre guide su percorsi di attacco ai trust e su audit del filtro SID e dell'autenticazione selettiva.

Password macchina dei domain controller: automatica finché qualcosa non la blocca

Anche i domain controller sono membri del dominio, e i loro account computer si ruotano secondo la stessa pianificazione Netlogon di una workstation. La KB 154501 di Microsoft lo dichiara senza mezzi termini: a partire dai computer basati su Windows 2000, la password dell'account macchina cambia automaticamente ogni 30 giorni (Disable machine account password changes). La policy che governa l'intervallo consente un numero di giorni definito dall'utente compreso tra 1 e 999, con un valore predefinito effettivo di 30 giorni tanto sui domain controller quanto sui server membri e sui client.

Un DC la cui password computer non si muove da mesi non è quindi una scelta di policy: è un segnale. Il checkpoint ANSSI Domain controllers with passwords unchanged for more than 45 days è inequivocabile: alcuni domain controller non hanno cambiato la propria password da oltre 45 giorni, il che indica che i loro segreti non vengono rinnovati, e occorre indagare il motivo per cui questo cambio non avviene correttamente, poiché può essere indicativo di una compromissione.

I soliti colpevoli sono locali alla macchina:

• DisablePasswordChange impostato a 1 sotto HKLM\System\CurrentControlSet\Services\Netlogon\Parameters, che impedisce alla macchina di inviare mai un cambio — è questo il valore che congela il segreto proprio del domain controller.
• Un valore di MaximumPasswordAge spinto molto in alto, oppure una GPO che imposta silenziosamente uno dei due valori.
• Il servizio Netlogon non in esecuzione, oppure un canale sicuro già interrotto.

C'è un valore di registro che qui viene spesso incolpato a torto. RefusePasswordChange impostato a 1 fa sì che il domain controller rifiuti le richieste di cambio password solo da workstation o server membri che eseguono Windows NT versione 4.0 o successiva — congela le password computer dei tuoi membri, non quella del DC stesso. Controllalo quando sono gli oggetti membro a smettere di ruotare: con RefusePasswordChange, il traffico di replica si interrompe, ma non quello client, mentre DisablePasswordChange interrompe entrambi.

Vale la pena ripetere l'avvertimento di Microsoft su cosa comporti disattivare questa funzione: se disabiliti i cambi di password dell'account macchina, ci sono rischi di sicurezza perché il canale sicuro viene usato per l'autenticazione pass-through; se qualcuno scopre una password, può potenzialmente eseguire un'autenticazione pass-through verso il domain controller. La documentazione delle policy aggiunge l'altra metà del quadro: aumentare in modo significativo l'intervallo di cambio password (o disabilitare del tutto i cambi) dà a un attaccante più tempo per condurre un attacco di brute-force contro la password di uno degli account macchina.

Il segreto di un account macchina è anche materiale per i service ticket di tutto ciò che gira su quell'host: è il meccanismo dietro un attacco Silver Ticket — e su un domain controller, le anomalie attorno all'oggetto computer meritano lo stesso livello di attenzione di una sorgente di replica inattesa, il trucco usato da DCShadow. Per il quadro più ampio sull'identità delle macchine, vedi il nostro approfondimento sulla superficie di attacco degli oggetti computer.

Detection

Tre query, eseguite da una workstation amministrativa aggiunta al dominio con RSAT, coprono l'intero terzetto.

1. Gli account krbtgt, inclusi quelli per singolo RODC:

Get-ADUser -Filter "SamAccountName -like 'krbtgt*'" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet, Enabled

2. Gli account di trust interdominio, risolti a partire dagli stessi TDO:

Get-ADObject -Filter "objectClass -eq 'trustedDomain'" -Properties flatName, trustDirection |
    ForEach-Object {
        Get-ADUser -Identity ('{0}$' -f $_.flatName) -Properties PasswordLastSet -ErrorAction SilentlyContinue |
            Select-Object SamAccountName, PasswordLastSet
    }

Gli stessi account possono essere elencati direttamente tramite il flag INTERDOMAIN_TRUST_ACCOUNT — decimale 2048, esadecimale 0x0800 — usando la matching rule LDAP_MATCHING_RULE_BIT_AND con OID 1.2.840.113556.1.4.803 (Search Filter Syntax):

Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=2048)" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

3. Ogni oggetto computer dei domain controller:

Get-ADDomainController -Filter * | ForEach-Object {
    Get-ADComputer $_.ComputerObjectDN -Properties PasswordLastSet |
        Select-Object Name, PasswordLastSet
}

Confronta l'output con queste soglie:

I segnali corrispondenti nei log eventi:

L'evento 4742 viene generato solo sui domain controller, il che rende sufficiente la raccolta lato DC per questo controllo. Su una macchina sospetta, nltest /sc_query:<domain> restituisce ERROR_ACCESS_DENIED quando il canale sicuro è interrotto (Broken trust relationship between a domain-joined device and its domain).

Remediation

🚨 Pericolo: non eseguire mai i due reset di krbtgt uno dopo l'altro. Il secondo reset, prima che il primo si sia replicato completamente, invalida i ticket in tutto il dominio e può mandare in crisi l'autenticazione insieme a essi.

Ruotare krbtgt, in fasi

1. Verifica prima la replica. La procedura a due reset funziona solo se ogni domain controller ha già visto la prima nuova password prima che arrivi la seconda, quindi conferma che la replica sia sana prima di iniziare. repadmin /replsummary identifica i domain controller che stanno fallendo la replica in ingresso o in uscita e riassume i risultati in un report.
2. Esegui un primo reset, usando la procedura supportata descritta in AD Forest Recovery - Reset the krbtgt password. La password che digiti è irrilevante: il sistema ne genera automaticamente una robusta, indipendentemente da quella che specifichi.
3. Attendi. Microsoft: bisogna eseguire questa operazione due volte, e occorre attendere 10 ore tra un reset e l'altro; 10 ore corrispondono ai valori predefiniti delle policy Maximum lifetime for user ticket e Maximum lifetime for service ticket, quindi se il valore di Maximum lifetime cambia, il periodo minimo di attesa tra i reset deve essere superiore al valore configurato. Considera le 10 ore come un minimo, non un obiettivo: in una foresta grande o con replica lenta, lasciare un giorno intero tra i due reset non costa nulla.
4. Esegui un secondo reset. Entrambi i reset sono necessari perché il valore di password history dell'account krbtgt è 2, il che significa che include le due password più recenti — un solo reset lascia la chiave precedente ancora presente nella cronologia e ancora utilizzabile. Microsoft: eseguendo il reset due volte si ripulisce di fatto la cronologia da qualsiasi vecchia password, così nessun altro DC può replicarsi con questo DC usando una password vecchia.
5. Mettilo in calendario. Defender for Identity inizia a segnalare l'account a 180 giorni, il che rende una rotazione due volte l'anno un default difendibile. Qualunque intervallo tu scelga, la rotazione esiste davvero solo se qualcuno se ne assume la responsabilità.

Correggere una password di trust non aggiornata

1. Stabilisci se il trust esiste ancora. Confronta gli account di trust che hai trovato con i TDO effettivamente attivi. La remediation ANSSI per gli orfani è diretta: alcuni account di trust possono restare presenti anche dopo che le relative relazioni di trust sono state rimosse, e vanno eliminati manualmente.
2. Per un trust ancora attivo, verifica il canale sicuro prima di toccare qualsiasi cosa: netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify — il parametro /verify verifica i segreti del canale sicuro per una specifica relazione di trust (netdom trust).
3. Indaga prima di reimpostare. Una password di trust che non si muove da mesi significa che il PDC emulator del dominio trusting non è riuscito a completare lo scambio — controlla la connettività verso il partner, lo stato di salute del ruolo PDC emulator e la replica del TDO su entrambi i lati, tenendo a mente la regola N-2 vista sopra.
4. Reimposta il segreto del trust solo all'interno di una change window, con credenziali su entrambi i lati: netdom trust <TrustingDomain> /domain:<TrustedDomain> /userd:<TrustedDomain>\admin /passwordd:* /reset. Il parametro /reset reimposta il segreto del trust tra domini trusted oppure tra il domain controller (DC) e la workstation.

Far ripartire la rotazione su un domain controller

1. Conferma che il servizio sia in esecuzione: sc.exe query netlogon.
2. Controlla i due valori di registro Netlogon sotto HKLM\System\CurrentControlSet\Services\Netlogon\Parameters — la remediation ANSSI prevede che DisablePasswordChange sia 0 o assente e che MaximumPasswordAge sia 30, e chiede di confermare che nessuna GPO li stia sovrascrivendo.
3. Verifica che la password macchina corrisponda a quella nella directory: nltest /sc_verify:<NetBIOSDomainName> dovrebbe restituire 0 0x0 NERR_Success.
4. Se il DC è fuori sincronia perché è stato ripristinato da uno stato precedente, trattalo come una riparazione del canale sicuro, non come un problema di rotazione — Microsoft documenta entrambe le direzioni del disallineamento (il dispositivo più recente della AD, e la AD più recente del dispositivo).

L'igiene di rotazione si affianca al resto della tua postura sulle credenziali — policy deboli, password che non scadono mai e storage in chiaro sono trattati in Sicurezza delle password in Active Directory, e i tre controlli visti sopra si integrano direttamente in un più ampio audit di sicurezza di Active Directory.

Come EtcSec rileva questo

Un audit EtcSec controlla tutti e tre i segreti nello stesso passaggio. ANSSI_R28_KRBTGT_NOT_ROTATED (Critico) legge pwdLastSet su ogni account krbtgt e segnala i domini oltre la soglia di 180 giorni. ANSSI_R42_TRUST_PASSWORD_OLD (Alto) risolve ogni oggetto trusted domain nel relativo account di trust interdominio e riporta le password che hanno smesso di ruotare — inclusi gli account orfani lasciati dai trust eliminati. ANSSI_R43_DC_PASSWORD_OLD (Alto) e COMPUTER_PASSWORD_OLD confrontano ogni domain controller e ogni oggetto computer membro con la cadenza Netlogon di 30 giorni, così un canale sicuro bloccato emerge come finding invece che come ticket di supporto sei mesi dopo. GOLDEN_TICKET_RISK collega il risultato su krbtgt a ciò che un attaccante fa davvero con una chiave che non cambia mai.

Fonti primarie

• Microsoft — AD Forest Recovery: Reset the krbtgt password
• Microsoft — Accounts security posture assessment (Defender for Identity)
• Microsoft — How Domain and Forest Trusts Work
• Microsoft — UserAccountControl property flags (KB 305144)
• Microsoft — Disable machine account password changes (KB 154501)
• Microsoft — Domain member: Maximum machine account password age
• Microsoft — MS-ADTS: Essential Attributes of Interdomain Trust Accounts
• Microsoft — 4742(S): A computer account was changed e 4724(S, F): An attempt was made to reset an account's password
• Microsoft (archiviato) — New-KrbtgtKeys.ps1, in sola lettura dall'8 marzo 2024
• ANSSI / CERT-FR — Points de controle Active Directory (CERTFR-2020-DUR-001), raccolta dei checkpoint su cert.ssi.gouv.fr/uploads/ad_checklist.html — checkpoint Trust account passwords unchanged for more than a year e Domain controllers with passwords unchanged for more than 45 days