Rotazione KRBTGT in Active Directory: runbook operativo senza outage

Indice

• Obiettivo e limite del runbook
  • L'account krbtgt: cosa è e cosa non fare
  • Cosa indica la finestra $W$
• Quando avviare la rotazione
• Rilevare compromissione DC, Golden Ticket e restore non autorizzati
  • Segnali di possibile compromissione di un Domain Controller
  • Furto chiave KRBTGT e sospetto Golden Ticket
  • Ripristini non autorizzati e virtualizzazione
  • Microsoft Sentinel, Defender e Zabbix
• Prerequisiti e criteri go/no-go
  • Checklist tecnica
  • Controlli di salute pre-change
  • Matrice dei prerequisiti e dei permessi necessari
• Foreste multi-domain: pianificazione e sequenza
  • Inventario e ordine decisionale
  • Procedura per ogni dominio
  • Controlli cross-domain e trust
• Server cloud e servizi con ticket persistenti
  • Inventario cloud pre-change
  • Sequenza sicura per member server cloud
• Piano temporale sicuro
• Esecuzione: primo reset
• Intervallo di osservazione e decisione sul secondo reset
• Esecuzione: secondo reset
  • Se il secondo reset fallisce o causa un impatto
• Validazione post-change
  • Test di autenticazione
  • Query di telemetria iniziale
• Risposta agli errori e rollback operativo
• Evidenze da chiudere nel change
• Errori da evitare
• Modello operativo, ruoli e comunicazione
  • Comunicazione minima
  • Criteri di escalation
• Inventario di dominio e raccolta evidenze ripetibile
  • Mappa dei DC e dei siti
  • Trust, domini e identità esterne
• Calcolo e approvazione della finestra W
  • Checkpoint prima del secondo reset
• Validazione replica per Domain Controller
• Matrice dei test funzionali
• Triage dei failure Kerberos
• Monitoraggio rinforzato e riesame
  • Riesame dopo la chiusura
• Checklist finale

Obiettivo e limite del runbook

L'account krbtgt: cosa è e cosa non fare

krbtgt è un account integrato speciale creato in ogni dominio Active Directory. E disabilitato per l'accesso interattivo e non rappresenta un vero utente o un servizio che debba effettuare logon. La password dell'account non è tuttavia inattiva: il Key Distribution Center (KDC) dei Domain Controller la usa per firmare e cifrare i Ticket Granting Ticket (TGT) Kerberos del dominio.

La password e le chiavi Kerberos dell'account sono sempre gestite da Active Directory. Un operatore può tecnicamente eseguire un reset oppure fornire una password esplicita con strumenti AD autorizzati, ma il cambio viene comunque registrato e replicato da AD: vengono aggiornati gli attributi di password, le chiavi Kerberos derivate e il Key Version Number (KVNO). Il KDC usa questo stato replicato, non una password conservata localmente dall'operatore.

L'account krbtgt non deve mai essere eliminato, rinominato, abilitato, spostato o modificato manualmente. La sua disabilitazione è prevista dal design; abilitarlo non risolve problemi Kerberos e aumenta inutilmente la superficie di attacco. Anche se è possibile impostare una password scelta manualmente, non farlo in questo runbook: usa soltanto il reset controllato nel workflow approvato, che protegge il segreto e registra la doppia rotazione.

Un ambiente con Read-Only Domain Controller (RODC) contiene anche gli account krbtgt_<numero>, che appartengono agli RODC. Questi account sono esclusi dalla rotazione standard del dominio. Ogni account di questo tipo è associato a uno specifico RODC e possiede una chiave Kerberos distinta, usata dall'RODC per i ticket che emette. Non è il krbtgt del dominio: la sua gestione richiede un runbook RODC specifico, con valutazione della Password Replication Policy, dell'eventuale compromissione dell'RODC e del perimetro dei credential cache.

Il comando seguente è solo diagnostico e consente di inventariare gli account senza modificare Active Directory:

$Domain = "contoso.com"
Get-ADUser -LDAPFilter "(sAMAccountName=krbtgt*)" -Server $Domain `
	-Properties Enabled, PasswordLastSet, msDS-KeyVersionNumber, Description |
	Select-Object SamAccountName, Enabled, PasswordLastSet, msDS-KeyVersionNumber, Description |
	Sort-Object SamAccountName

L'output deve mostrare l'account krbtgt del dominio come disabilitato e, se sono presenti RODC, gli account krbtgt_<numero> separatamente. Registra questi ultimi come esclusi dallo scope del change e verifica con il team AD se un RODC necessita una risposta distinta.

La password dell'account krbtgt firma e cifra i Ticket Granting Ticket (TGT) Kerberos emessi da un dominio Active Directory. Microsoft raccomanda di ruotarla ogni sei mesi come controllo pianificato; non è però una manutenzione da eseguire arbitrariamente o durante un cambio infrastrutturale non stabilizzato. Quando esiste il sospetto che la chiave sia stata esposta, la rotazione diventa una misura di containment da avviare con incident response, senza attendere la cadenza semestrale.

Questo runbook descrive una rotazione per un singolo dominio scrivibile. Ogni dominio della foresta ha il proprio account krbtgt e richiede una valutazione e un change separati. Gli account RODC restano fuori dallo scope, come indicato sopra.

Il principio che governa tutto il change è semplice: il primo reset introduce la nuova chiave mantenendo la precedente per validare TGT esistenti; il secondo reset, eseguito solo dopo replica completa e attesa sufficiente, rimuove anche la chiave che poteva essere nota a un attaccante.

Non esiste un rollback normale della password KRBTGT. Reimpostare la password precedente e un nuovo cambio password in Active Directory: AD genera e replica un nuovo stato delle chiavi e incrementa di nuovo il KVNO. Questa azione non ripristina le chiavi storiche precedenti, i ticket precedenti o lo stato di replica precedente. La decisione sicura è fermarsi dopo il primo reset se la validazione non è soddisfacente; un ripristino di Active Directory è un'operazione di forest recovery, non un rollback del change.

Cosa indica la finestra $W$

In questo runbook, $W$ è l'intervallo di sicurezza tra il primo e il secondo reset della password KRBTGT per uno specifico dominio. Non è una generica maintenance window e non è il tempo totale del change. Parte soltanto dopo che il primo reset è stato verificato e replicato su tutti i Domain Controller scrivibili del dominio.

La finestra $W$ deve essere lunga abbastanza per due condizioni: il primo cambio deve raggiungere tutti i DC scrivibili e i TGT firmati con la chiave precedente devono scadere. Per questo il valore non può essere deciso solo dal calendario; dipende dalla replica osservata, dal valore effettivo di MaxTicketAge e da un margine operativo. La sezione Piano temporale sicuro calcola e approva il valore; fino a quel checkpoint, $W$ indica sempre questa attesa obbligatoria e non un tempo arbitrario.

Quando avviare la rotazione

Apri un incident/change ad alta priorità quando una delle seguenti condizioni è confermata o ragionevolmente sospetta:

• compromissione di un Domain Controller o acquisizione di NTDS.dit, backup di sistema o dump della memoria LSASS di un DC;
• furto della chiave KRBTGT, uso sospetto di Golden Ticket o anomalie TGT non spiegabili;
• ripristino non autorizzato, clonazione impropria o perdita di controllo di un DC;
• indicazione del team incident response dopo una compromissione Tier 0.

La cadenza semestrale raccomandata da Microsoft può essere adottata nella policy aziendale, ma non sostituisce hardening, monitoraggio e risposta all'incidente. Prima di ogni reset pianificato, verifica che l'ambiente sia sano e che il rischio operativo sia accettato dal change owner. In caso di compromissione confermata o sospetta, non attendere la cadenza semestrale pianificata: segui la sequenza di containment e le decisioni del team incident response.

Riferimenti Microsoft: KRBTGT account password reset scripts, Kerberos policy settings, AD forest recovery.

Rilevare compromissione DC, Golden Ticket e restore non autorizzati

Il reset KRBTGT non deve essere l'unico segnale che qualcosa e accaduto. Non esiste un singolo Event ID che provi il furto della chiave KRBTGT: va correlato un insieme di segnali provenienti dai DC, dai sistemi che li ospitano, dai servizi che ricevono ticket e dalla telemetria di sicurezza. L'obiettivo e distinguere un problema operativo da un possibile accesso Tier 0 e conservare evidenze prima di modificare l'ambiente.

Segnali di possibile compromissione di un Domain Controller

Tratta come indizi da investigare, non come prova autonoma, i seguenti eventi o pattern:

• accesso amministrativo anomalo al DC, inclusi 4624, 4672, 4648 e 4625, da host, account o orari inattesi;
• modifica di gruppi privilegiati, audit policy o oggetti AD sensibili, ad esempio 4728/4729, 4732/4733, 4719 e 4662 quando Directory Service Access auditing e configurato;
• creazione di servizio, task o processo inatteso sul DC, inclusi 4697, 7045 e 4688 quando il process command line auditing e abilitato;
• cancellazione del Security log (1102), arresti/riavvii inattesi o perdita di telemetria del DC;
• errori di replica, modifica inattesa di invocation ID, metadati incoerenti o segnali di restore da backup nel Directory Service log e in repadmin;
• alert EDR/Microsoft Defender for Identity su DCSync, credential dumping, lateral movement, modifica anomala di configurazione AD o attivita privilegiata su un DC.

Prima di ruotare KRBTGT, l'incident commander deve decidere quali sistemi isolare e quali log preservare. Spegnere, riavviare o forzare la replica di un DC sospetto senza istruzioni forensi puo cancellare memoria volatile o modificare la timeline dell'incidente.

Furto chiave KRBTGT e sospetto Golden Ticket

Il furto materiale della chiave non e normalmente visibile come un evento Windows dedicato. Cerca invece anomalie nel modo in cui vengono usati i TGT: account privilegiati che compaiono su host insoliti, ticket con durata o proprieta incoerenti con la policy, accessi a servizi senza un 4768 atteso nella finestra di correlazione e alert di Microsoft Defender for Identity o EDR relativi a uso sospetto di Kerberos/Golden Ticket.

Confronta PasswordLastSet e KVNO del dominio con la telemetria: un ticket associato a una chiave precedente dopo il completamento della doppia rotazione, oppure pattern persistenti di autenticazione privilegiata da endpoint inattesi, richiede triage immediato. Non dedurre il furto della chiave dal solo 4769 o dal solo fallimento di un'applicazione: correlare sempre utente, client, DC, servizio, ticket lifetime e alert di sicurezza.

Ripristini non autorizzati e virtualizzazione

Un restore non autorizzato di un DC puo lasciare segnali in Directory Service, System, backup platform e replica AD. Verifica repadmin /showrepl, metadati di replica, DNS/SYSVOL e il log della piattaforma virtuale o cloud per restore, snapshot revert, clonazione o sostituzione VM non pianificati. Se il DC e virtualizzato, confronta anche inventario VM, backup job, change approvati e proprietario dell'azione.

Il VM-Generation ID riduce alcuni rischi di virtualizzazione, ma non rende un restore non autorizzato un evento innocuo. Trattalo come incidente finche il team AD e IR non ha stabilito coerenza di replica, provenienza del backup e integrita del DC.

Microsoft Sentinel, Defender e Zabbix

Microsoft Sentinel puo correlare i Security Event dei DC, gli alert Microsoft Defender for Identity/Defender XDR e i log di sistema. Crea regole che confrontino la baseline con il periodo prima/dopo il reset e inviano alert al SOC, non alert automatici che eseguono nuovi reset. Adatta i nomi di tabella al connettore effettivamente configurato nel tenant.

SecurityEvent
| where TimeGenerated > ago(4h)
| where EventID in (4624, 4625, 4672, 4719, 4768, 4769, 4771, 1102)
| summarize Events=count(), Accounts=make_set(Account, 20), Hosts=make_set(Computer, 20)
	by EventID, bin(TimeGenerated, 15m)
| order by TimeGenerated desc

In Zabbix, raccogli da ogni DC i Security/System/Directory Service event tramite agent o Windows event log item e aggiungi metriche di servizio, reachability, spazio disco, DNS e replica esposta da check script read-only. Configura trigger su: assenza prolungata di dati da un DC, aumento rispetto alla baseline di 4771/4625, event 1102, errori di replica o arresto di AD DS/DNS/DFSR. La soglia deve considerare il normale volume del dominio: un semplice conteggio assoluto di 4768 o 4769 genera falsi positivi nei picchi di login.

Zabbix e Sentinel devono puntare allo stesso change ID e alla stessa baseline temporale. Conserva il grafico o l'export degli alert nel ticket, indicando fuso orario, DC monitorati e sorgente log; questa prova e piu utile di uno screenshot isolato preso dopo un incidente.

Prerequisiti e criteri go/no-go

Nomina prima della modifica un change owner, un operatore AD, un responsabile di monitoring/SOC, un escalation owner per applicazioni critiche e un decisore con autorità di fermare il secondo reset. Conserva nel ticket nomi, reperibilità e finestra approvata.

Checklist tecnica

• Inventario aggiornato di tutti i DC scrivibili, siti AD, versioni OS e ruoli FSMO.
• Salute di replica AD e SYSVOL verificata senza errori correnti o backlog non spiegato.
• Backup System State recente, ripristinabile e testato secondo il piano di disaster recovery. Un backup non è un rollback immediato.
• Nessun DC in maintenance, demotion/promotion, migrazione, snapshot restore o ripristino autorevole.
• DNS, time service e connettività tra siti funzionanti; la deriva oraria Kerberos resta entro i limiti aziendali.
• Durata effettiva delle policy Kerberos documentata: MaxTicketAge, MaxRenewAge, MaxServiceAge e clock skew.
• Health check applicativi e account di test definiti per VPN, VDI, file server, applicazioni web integrate, SQL e servizi Tier 0.
• Change freeze, backup window e job critici esclusi dalla finestra; comunicazione pronta per service desk e owner.
• Privilegi delegati e workstation amministrativa Tier 0 disponibili; non usare una sessione amministrativa da endpoint non fidato.

Controlli di salute pre-change

Esegui i comandi da una workstation amministrativa con RSAT, salvando gli output nel ticket. Sostituisci contoso.com con il dominio target.

$Domain = "contoso.com"
Get-ADDomainController -Filter * -Server $Domain |
	Select-Object HostName, Site, IsGlobalCatalog, OperationMasterRoles

repadmin /replsummary
repadmin /showrepl * /errorsonly
dcdiag /e /test:Advertising /test:Replications /test:SysVolCheck /test:DNS

Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber |
	Select-Object SamAccountName, PasswordLastSet, msDS-KeyVersionNumber, Enabled

repadmin /replsummary deve risultare pulito. Un singolo errore di replica, un DC irraggiungibile o SYSVOL non pronto è un criterio no-go: correggi prima la causa. Annotare anche PasswordLastSet e msDS-KeyVersionNumber iniziali; il KVNO deve avanzare a ogni reset.

Per acquisire le policy Kerberos effettive sul PDC Emulator:

$Pdc = (Get-ADDomain -Server $Domain).PDCEmulator
Get-ADDefaultDomainPasswordPolicy -Server $Domain |
	Format-List MaxTicketAge, MaxServiceAge, MaxRenewAge

Get-GPResultantSetOfPolicy -ReportType Html -Path .\kerberos-rsop.html

Get-ADDefaultDomainPasswordPolicy non sostituisce RSOP se una GPO assegna impostazioni Kerberos: usa il report RSOP e la GPMC per ottenere il valore effettivo applicato ai DC.

Matrice dei prerequisiti e dei permessi necessari

La tabella separa i diritti necessari per leggere, validare e modificare. Non usare Enterprise Admins come scelta predefinita: la rotazione è un'operazione per dominio e richiede privilegi nel dominio da gestire. Per impostazione predefinita, un membro di Domain Admins del dominio target dispone dei diritti necessari; un modello least-privilege deve essere delegato e testato prima della finestra.

Attività	Permesso o ruolo minimo	Prova pre-change	Nota di sicurezza
Leggere DC, krbtgt e policy	Lettura AD e RSAT ActiveDirectory	Eseguire i comandi baseline senza errori	Usare account separato se il modello prevede read-only
Resettare la password krbtgt	Diritto esteso Reset Password delegato sull'oggetto krbtgt, oppure Domain Admins nel dominio target	Testare la delega in lab o con controllo di autorizzazione approvato	Non usare credenziali Enterprise Admin solo per comodità
Forzare/analizzare replica e dcdiag	Privilegi amministrativi previsti sui DC e strumenti RSAT/AD DS	Eseguire repadmin e dcdiag nel perimetro target	Non bypassare UAC o usare credenziali condivise
Leggere Security/System log DC	Membership o delega Event Log Readers equivalente su ogni DC	Interrogare eventi 4768/4769/4771 e System	Il SOC può avere lettura senza diritto di reset
Testare applicazioni	Account di test a privilegio minimo, autorizzato dall'owner	Login nuovo e test di servizio definiti	Non usare un Domain Admin come unico test
Approvare il secondo reset	Change owner autorizzato	Decisione go/hold/no-go registrata	L'approvazione non sostituisce i controlli tecnici

Se usi una delega custom, verifica il diritto effettivo prima della finestra con un account non amministratore globale. Il test non deve resettare krbtgt in produzione: valida la ACL dell'oggetto, il gruppo delegato e il processo in un dominio lab o tramite il controllo di accesso approvato. Conserva nel change la richiesta di accesso, il gruppo usato, la scadenza dell'elevazione e il nominativo dell'operatore.

L'account operativo deve essere protetto da MFA/PIM o da un controllo equivalente, usato soltanto dalla PAW prevista e rimosso dalla sessione al termine del lavoro. Se viene applicata elevazione just-in-time, attivala abbastanza prima della finestra per convalidare replica, log e tool, ma non lasciarla attiva senza necessità fino al secondo reset.

Foreste multi-domain: pianificazione e sequenza

In una foresta multi-domain non esiste un singolo krbtgt condiviso. Ogni dominio scrivibile, compreso il forest root domain, possiede un proprio account krbtgt, proprie policy Kerberos, DC, siti e ticket. Resettare krbtgt in child.contoso.com non ruota quello di contoso.com o di un altro child domain e viceversa.

Tratta quindi il lavoro come un programma coordinato di change per dominio, non come un singolo comando forest-wide. Ogni dominio deve avere: scope, owner, account operativo, baseline, $W$, evidenze di replica, test locali e checkpoint propri. Il ticket master deve collegare tutti i change figli e fermare la sequenza se uno di essi non raggiunge il go/no-go previsto.

Inventario e ordine decisionale

Prima di scegliere l'ordine, raccogli la topologia e i trust dal forest root con privilegi di lettura adeguati:

$Forest = Get-ADForest -Server "contoso.com"
$Forest.Domains | ForEach-Object {
	$Domain = $_
	$DomainInfo = Get-ADDomain -Server $Domain
	[pscustomobject]@{
		Domain = $Domain
		PdcEmulator = $DomainInfo.PDCEmulator
		DomainMode = $DomainInfo.DomainMode
		WritableDcCount = (Get-ADDomainController -Filter * -Server $Domain).Count
	}
} | Format-Table -AutoSize

Get-ADTrust -Filter * -Server "contoso.com" |
	Select-Object Name, Direction, TrustType, ForestTransitive, SelectiveAuthentication |
	Format-Table -AutoSize

Questo inventario non stabilisce automaticamente la sequenza. L'ordine deve seguire il blast radius, la dipendenza dei servizi e la disponibilità degli owner. In assenza di un vincolo applicativo documentato, una pratica prudente è lavorare prima sui child domain con minore criticità e pianificare il forest root domain solo dopo aver verificato processo, telemetria e comunicazione. Se il sospetto di compromissione riguarda il forest root o più domini, la sequenza deve essere diretta dall'incident commander e dal piano forest recovery, non da una regola generica.

Procedura per ogni dominio

1. Seleziona il dominio target e usa credenziali valide in quel dominio; non assumere che l'accesso nel root abiliti il reset nel child.
2. Esegui tutti i controlli pre-change con -Server <dominio-target> e identifica il relativo PDC Emulator.
3. Valida i flussi intra-domain e cross-domain critici con account e servizi concordati.
4. Esegui il primo reset soltanto nel dominio target, verifica replica su tutti i suoi DC scrivibili e avvia il suo timer $W$.
5. Durante $W$, non sovrapporre una seconda rotazione in un dominio con gli stessi servizi critici, salvo decisione IR esplicita e testata.
6. Al checkpoint, esegui il secondo reset per quel dominio solo se i suoi criteri sono soddisfatti; completa la validazione prima di avviare il dominio successivo.

La serializzazione è la scelta preferibile quando la foresta ha pochi owner, trust complessi o applicazioni che attraversano domini. Change paralleli sono possibili solo con domini indipendenti, team distinti, telemetria separata e una decisione che accetti il blast radius cumulativo. Non usare parallelismo per recuperare ritardi di pianificazione.

Controlli cross-domain e trust

Per ogni trust business-critical, definisci una matrice con dominio origine, dominio risorsa, account di test, SPN/FQDN del servizio, owner e risultato atteso. Esegui una baseline prima del primo dominio e ripeti il test dopo il secondo reset di ciascun dominio che partecipa al flusso.

Flusso	Baseline	Dopo dominio origine	Dopo dominio risorsa
Utente child -> file server root	Nuovo logon e SMB via FQDN	TGT e accesso riusciti	Ticket servizio e accesso riusciti
Utente root -> IIS child	Login integrato, nessun prompt	4768/4769 coerenti	Ticket HTTP e risposta applicativa
Account applicativo -> SQL altro dominio	Health query integrata	Nessun errore trust/pre-auth	Query e job pianificato riusciti

Se il trust usa selective authentication, verifica anche il diritto Allowed to authenticate sulle risorse target; non attribuire una negazione di autorizzazione al reset KRBTGT senza leggere l'evento e la configurazione trust. Un external trust non viene "coperto" dal fatto che la replica intra-domain sia sana.

Server cloud e servizi con ticket persistenti

Le VM IaaS in Azure, AWS o GCP che sono domain-joined sono member server dal punto di vista Kerberos, ma possono avere cicli operativi diversi: autoscaling, immagini golden, servizi sempre attivi, manutenzione dell'host, rete site-to-site e processi che mantengono ticket o connessioni molto a lungo. Un TGT dovrebbe essere rinnovato secondo la policy, ma non dare per scontato che ogni servizio long-running aggiorni la propria cache, riesegua un logon o riapra una connessione Kerberos nel momento previsto.

Per questi sistemi, il riavvio controllato o il restart del servizio è spesso il modo più affidabile per ottenere una nuova sessione Kerberos. Non è una conseguenza automatica del reset, non va eseguito indiscriminatamente e non sostituisce il controllo di ticket, log e health check.

Inventario cloud pre-change

Classifica ogni server cloud domain-joined in una delle seguenti categorie e definisci azione, owner e finestra:

Categoria	Esempi	Azione durante il change	Criterio di successo
Stateless dietro load balancer	Web tier, API, worker replicati	Drain, riavvio rolling e re-enable health probe	Nuova istanza healthy e SSO valido
Stateful	SQL, file server, middleware, license server	Riavvio solo con runbook applicativo e failover testato	Dati coerenti e health check applicativo
Autoscaling/image-based	VMSS, ASG, MIG, golden image	Bloccare rollout automatici; verificare join e bootstrap delle nuove istanze	Nuove istanze domain-joined e raggiungibili
Management/jump host	Bastion, PAW cloud, server di gestione	Nuova sessione e riavvio pianificato se mantiene ticket	Tool amministrativi e secure channel validi
Domain Controller cloud	DC IaaS in una subnet AD	Non riavviare per "refresh" senza valutazione replica e change DC	Replica, DNS e SYSVOL sani

Annota provider, subscription/account/project, regione, subnet, tag di criticità, availability set/zone, metodo di accesso, owner e dipendenze on-premises. Un server cloud non raggiungibile durante la finestra è un gap di validazione, non un motivo per ignorarlo.

Sequenza sicura per member server cloud

1. Metti in pausa deployment, autoscaling replacement e patch automation che potrebbero introdurre istanze nuove mentre raccogli la baseline.
2. Verifica VPN/ExpressRoute/Direct Connect, DNS interno, NTP e raggiungibilità di almeno due DC del dominio corretto dalla subnet cloud.
3. Esegui health check applicativo e controlla il secure channel prima del primo reset.
4. Dopo il primo reset e replica, verifica ticket e servizio; pianifica restart del servizio o reboot rolling se il processo non rinnova la sessione o il vendor lo richiede.
5. Per pool con load balancer, esegui drain, riavvio di una sola istanza, health check e test SSO prima di procedere all'istanza successiva.
6. Dopo il secondo reset, ripeti il test a freddo; riattiva automazioni solo dopo che le nuove e le vecchie istanze sono conformi.

Esempio di controllo remoto da usare su un member server autorizzato. Questo script non esegue il restart: raccoglie solo le evidenze che determinano se serve pianificarlo.

$CloudMemberServer = "app-az-01.contoso.com"
Invoke-Command -ComputerName $CloudMemberServer -ScriptBlock {
	hostname
	Test-ComputerSecureChannel -Verbose
	nltest /sc_verify:contoso.com
	klist tickets
	w32tm /query /status
	Resolve-DnsName contoso.com
}

Prima di un reboot, l'owner deve confermare drain completato, backup/snapshot applicativo secondo policy, assenza di job critici, metodo console out-of-band e verifica del ritorno nel load balancer. Per database, cluster, server con dischi condivisi o controller di dominio, usa il runbook del prodotto: Restart-Computer generico non è una procedura di failover.

Un server che non recupera dopo restart puo indicare DNS, routing, secure channel, GPO, certificati o dipendenze applicative. Mantieni l'istanza fuori dal pool, raccogli log e apri incident con l'owner; non ripetere i reset KRBTGT come tentativo di riparazione.

Piano temporale sicuro

La pausa tra i due reset deve consentire a tutti i DC di ricevere il primo cambiamento e far scadere i TGT firmati con la chiave precedente. Per il valore standard, Microsoft indica almeno 10 ore; in produzione usa una durata calcolata e approvata, non il default presunto.

Definisci:

$$W = \max(\text{replica completa osservata}, \text{MaxTicketAge effettivo}) + \text{margine operativo}$$

Il margine deve coprire la propagazione fra siti, ritardi di monitoraggio e la verifica manuale. Se MaxTicketAge e 10 ore, una finestra pratica comune è almeno 12 ore dopo la conferma di replica del primo reset. Se policy o topologia impongono un valore maggiore, prevale quello maggiore.

Fase	Azione	Uscita necessaria
T-7 giorni a T-1	Baseline, test e approvazioni	Tutti i criteri go soddisfatti
T0	Primo reset	KVNO incrementato e replica completa
T0 + W	Riesame telemetria e secondo reset	Nessun incidente non risolto; approvazione esplicita
T0 + W + replica	Validazione estesa	Health check e log entro la baseline
T0 + W + 1-7 giorni	Monitoraggio rinforzato	Evidenze archiviate e change chiuso

Non comprimere le fasi per "finire il giorno stesso". Il punto di controllo tra i reset è il confine operativo che evita di trasformare un sospetto di sicurezza in un outage generalizzato. Inoltre sono necessarie tempistiche tecniche per completare con successo la procedura.

Esecuzione: primo reset

Usa il KRBTGT Reset script Microsoft nella versione verificata dall'organizzazione, preferibilmente in modalità che consenta di scegliere un Domain Controller scrivibile e registrare l'azione. Prima di eseguirlo, leggi le istruzioni della versione scaricata e sottoponila al controllo del team security.

Se il processo approvato usa gli strumenti AD nativi, il comando equivalente è:

$Domain = "contoso.com"
$Before = Get-ADUser krbtgt -Server $Domain -Properties PasswordLastSet, msDS-KeyVersionNumber
$Before | Select-Object SamAccountName, PasswordLastSet, msDS-KeyVersionNumber

Set-ADAccountPassword -Identity krbtgt -Server $Domain -Reset

Get-ADUser krbtgt -Server $Domain -Properties PasswordLastSet, msDS-KeyVersionNumber |
	Select-Object SamAccountName, PasswordLastSet, msDS-KeyVersionNumber

Non impostare una password scelta manualmente, non disabilitare/rinominare/eliminare krbtgt e non eseguire reset concorrenti da console diverse. Il segreto deve essere generato e protetto dal workflow approvato.

Subito dopo, forza e verifica la replica. Il valore msDS-KeyVersionNumber, PasswordLastSet e gli attributi correlati devono risultare coerenti su ogni DC scrivibile:

repadmin /syncall $Pdc /AdeP
repadmin /replsummary
repadmin /showrepl * /errorsonly

Get-ADDomainController -Filter * -Server $Domain | ForEach-Object {
	Get-ADUser krbtgt -Server $_.HostName -Properties PasswordLastSet, msDS-KeyVersionNumber |
		Select-Object @{Name="DomainController";Expression={$_.PSComputerName}},
			PasswordLastSet, msDS-KeyVersionNumber
}

Nel risultato del ciclo, usare il nome del DC interrogato come etichetta se l'ambiente non popola PSComputerName. Non procedere finché ogni DC scrivibile non riporta il KVNO atteso e repadmin non è pulito.

Intervallo di osservazione e decisione sul secondo reset

Durante $W$, non modificare policy Kerberos, DNS, trust, servizi di autenticazione o topologia DC salvo per incidenti separati. Qualunque intervento rende ambigua la diagnosi.

Il SOC (Security Operation Center) o il sistema di monitoraggio deve cercare segnali di ticket Kerberos non validi e anomalie di autenticazione sui DC e sui servizi critici. Confronta conteggi e tassi, non solo la presenza di un singolo evento, con una baseline dello stesso giorno/orario della settimana.

Fonte	Segnali da osservare	Decisione
Security log DC	4768, 4769, 4771, 4776; picchi di failure code e client insoliti	Triage con owner prima del secondo reset
System log DC	KDC, Netlogon, Time-Service, DFS Replication	Stop se replica, DNS o tempo degradano
Servizi critici	4625, errori SSO, HTTP 401/5xx, login VPN/VDI, job falliti	Isolare app/account e testare con owner
SIEM/EDR	Golden Ticket suspicion, DC access anomalo, uso privilegiato	Escalare a incident response

Il secondo reset richiede l'approvazione esplicita del change owner soltanto quando: replica completa del primo reset, attesa $W$ terminata, test critici superati o con rischio accettato e nessun incidente aperto legato al change.

Esecuzione: secondo reset

Ripeti lo stesso metodo approvato, una sola volta, verso lo stesso dominio. Registra timestamp, operatore, DC contattato, KVNO prima/dopo e numero di change.

$BeforeSecondReset = Get-ADUser krbtgt -Server $Domain -Properties PasswordLastSet, msDS-KeyVersionNumber
$BeforeSecondReset | Select-Object SamAccountName, PasswordLastSet, msDS-KeyVersionNumber

Set-ADAccountPassword -Identity krbtgt -Server $Domain -Reset

repadmin /syncall $Pdc /AdeP
repadmin /replsummary
repadmin /showrepl * /errorsonly

Conferma che il KVNO sia incrementato una seconda volta su tutti i DC scrivibili. Poi riesegui i test e mantieni telemetria rinforzata. Non eseguire un terzo reset come tentativo di correzione: coinvolgi AD recovery e incident response.

Se il secondo reset fallisce o causa un impatto

Un errore restituito dal comando non dimostra che il reset non sia stato applicato. Prima di rieseguire qualsiasi comando, acquisisci timestamp, errore completo, DC contattato, PasswordLastSet e KVNO dal PDC Emulator e da ogni DC scrivibile. La decisione dipende dallo stato osservato, non dal solo codice di uscita della console.

Stato osservato	Come verificarlo	Azione immediata
Nessun KVNO o PasswordLastSet e cambiato	Query per DC, repadmin /replsummary, Security/Directory Service log	Non ritentare alla cieca; correggere privilegi, connettivita o errore del workflow e rivalutare il change
Il PDC mostra nuovo KVNO, uno o piu DC no	Query per DC, repadmin /showrepl * /errorsonly	Trattare come incidente di replica; bloccare test distruttivi e non eseguire un terzo reset
KVNO incrementato ovunque, ma servizi falliscono	Nuovo logon, klist, 4768/4769/4771 sul DC, 4625 e log app sul target	Aprire bridge incident, fermare rollout/restart non necessari e isolare servizio/account/host coinvolto
Autenticazioni falliscono su piu siti o Tier 0	Dashboard Sentinel/Zabbix, health check DC, DNS, tempo, replica	Escalare a incident commander e AD recovery owner; non tentare rollback tramite password precedente

Per verificare rapidamente lo stato dopo un esito ambiguo, riusa lo script di Validazione replica per Domain Controller e salva l'output con un nuovo timestamp. Poi esegui i test a freddo su un account standard e uno amministrativo dedicato, senza purgare ticket su host di produzione non coinvolti nel test.

Gli eventi da correlare durante il triage sono: 4768 per richiesta TGT, 4769 per ticket di servizio, 4771 per failure di pre-authentication, 4625 per logon falliti sui target, oltre ai log KDC, Netlogon, DNS, DFS Replication e Time-Service. La presenza di eventi non basta: confronta failure code, account, client, DC, servizio e tasso rispetto alla baseline. Se il Security log e stato cancellato (1102), se la telemetria sparisce o se compaiono alert DC/Golden Ticket, preserva le evidenze e passa al processo IR.

Se il secondo reset e confermato e l'impatto riguarda applicazioni specifiche, la risposta e remediation della dipendenza: SPN, DNS, clock skew, secure channel, trust, servizio o client. Se l'impatto e esteso, stabilizza prima replica, DNS e tempo con gli owner AD; la strategia di recovery deve essere definita dal piano forest recovery. Reimpostare una password vecchia o tentare un terzo reset non riporta indietro il dominio.

Validazione post-change

La validazione deve usare account di test a privilegi minimi e percorsi rappresentativi. Evita di usare solo la console amministrativa: una sessione già autenticata non dimostra il rinnovo dei ticket per gli utenti.

Test di autenticazione

1. Da una workstation di test, esegui klist purge, blocca/sblocca la sessione o effettua un nuovo logon controllato.
2. Esegui klist get krbtgt e verifica che venga ottenuto un TGT nuovo.
3. Accedi ai servizi definiti nel piano: file share via FQDN, applicazione IIS con Windows Integrated Authentication, SQL con Integrated Security, VPN/VDI e strumenti amministrativi Tier 0.
4. Verifica sul DC l'emissione dei nuovi 4768 e 4769 e sui target gli accessi riusciti 4624.
5. Ripeti il test da ogni sito AD significativo e per almeno un utente non amministrativo.

klist purge
klist get krbtgt
klist tickets

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:contoso.com

Test-ComputerSecureChannel e nltest verificano il secure channel del computer, non sostituiscono il test di una applicazione Kerberos. Un errore su un servizio deve essere correlato a SPN, DNS, account del servizio, trust e log del target prima di attribuirlo automaticamente alla rotazione.

Query di telemetria iniziale

Adatta queste query al SIEM e mantieni i risultati con intervallo temporale e fuso orario dichiarati:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769,4771; StartTime=(Get-Date).AddHours(-4)} |
	Group-Object Id | Select-Object Name, Count

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddHours(-4)} |
	Where-Object ProviderName -match 'Kerberos|KDC|Netlogon|DFSR|Time-Service' |
	Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

Gli Event ID descrivono una parte del flusso e non bastano da soli a dichiarare il change riuscito. La misura utile è l'assenza di un aumento anomalo dei failure code, unita al successo dei test applicativi e alla salute della replica.

Risposta agli errori e rollback operativo

Momento	Condizione	Azione immediata
Prima del primo reset	Replica, DNS o backup non conformi	No-go; correggere e ripianificare
Dopo il primo reset, prima del secondo	Failure Kerberos o servizio critico degradato	Fermare il piano, non eseguire il secondo reset, aprire bridge incident e raccogliere log
Dopo il secondo reset	Impatto diffuso di autenticazione	Incident response e AD recovery owner; stabilizzare DC, replica, DNS e tempo; non reimpostare KRBTGT alla cieca
In qualunque momento	Evidenza di compromissione attiva DC/Tier 0	Seguire il piano IR, isolare secondo decisione forense e valutare forest recovery

Il rollback operativo prima del secondo reset consiste nel non proseguire: la chiave precedente resta disponibile come chiave storica del KDC e i TGT già emessi continuano fino alla loro normale scadenza. Dopo il secondo reset, la riparazione dipende dalla causa. Cambiare ancora la password non ripristina i ticket vecchi, ma anzi, ne complica il contenimento.

Un restore di System State o di un DC senza un forest recovery plan puo introdurre USN rollback, divergence della replica o reinfezione. Solo il piano di recovery approvato, con ruoli e autorità appropriati, può stabilire se un ripristino è giustificato.

Evidenze da chiudere nel change

Archivia o collega nel ticket:

• scope del dominio, motivazione, approvazioni, operatori e timeline completa;
• output pre/post di repadmin, dcdiag, inventario DC e policy Kerberos/RSOP;
• timestamp e KVNO krbtgt prima, dopo primo reset e dopo secondo reset;
• prova della replica su ogni DC scrivibile e note su eventuali RODC esclusi;
• risultati dei test applicativi, account di test e owner che hanno approvato;
• dashboard SIEM con baseline, intervallo post-change, alert e relativo triage;
• decisione di chiusura, rischi residui e data del riesame post-change.

Errori da evitare

• eseguire due reset ravvicinati prima che tutti i DC abbiano replicato il primo;
• assumere che 10 ore siano sempre sufficienti senza leggere le policy effettive;
• includere RODC o altri domini senza una valutazione specifica;
• trattare errori di SPN, DNS, clock skew o trust come effetti inevitabili della rotazione;
• usare il reset come sostituto della risposta a un DC compromesso;
• dichiarare successo guardando solo il KVNO, senza testare l'autenticazione reale;
• pianificare un backup come "undo" immediato o eseguire restore non coordinati.

Modello operativo, ruoli e comunicazione

Una rotazione KRBTGT non è un'attività esclusivamente tecnica. Un reset riuscito a livello AD può comunque generare un incidente percepito dagli utenti se la comunicazione, la diagnostica e gli owner applicativi non sono pronti. Definisci i ruoli prima dell'inizio e non assegnare la stessa persona a operatore, approvatore e validatore di tutti i servizi critici.

Ruolo	Responsabilita prima del change	Responsabilita durante e dopo il change
Change owner	Approva scope, rischio, durata $W$ e piano di comunicazione	Decide go/no-go per il secondo reset e chiusura
Operatore AD	Esegue baseline, reset e verifica replica	Conserva output e coordina i controlli tecnici
SOC/monitoring	Prepara baseline, alert e dashboard	Triage alert, correla failure code ed escalation
Owner applicativo	Definisce test realistici e account autorizzati	Esegue test, classifica l'impatto e firma l'esito
Service desk	Riceve impatto previsto e criteri di escalation	Raccoglie segnalazioni e le collega al change
Incident commander	Verifica il percorso IR se il trigger e un sospetto di compromissione	Coordina containment e decisioni forensi

Comunicazione minima

La notifica non deve chiedere agli utenti di "provare se funziona". Deve indicare chiaramente il servizio, il periodo di osservazione, il canale di escalation e le informazioni necessarie per rendere riproducibile un problema.

Invia almeno questi messaggi:

1. Preavviso agli owner: dominio interessato, finestra, sistemi da testare, account di prova e orario previsto per il secondo reset.
2. Avviso al service desk: sintomi da associare al change, ad esempio errore SSO, richiesta ripetuta di credenziali, VPN rifiutata o accesso SMB negato; raccogli username, host client, destinazione, orario e screenshot/codice errore.
3. Aggiornamento al SOC: query, soglie di alert, DC nel perimetro e canale di escalation immediato.
4. Chiusura agli owner: esito, test completati, problemi residui, periodo di monitoraggio e punto di contatto per regressioni tardive.

Non comunicare il valore della password, dettagli di indagine forense, hash, ticket o indicatori sensibili in un ticket leggibile da gruppi non Tier 0. I dati tecnici necessari al SOC vanno conservati nella posizione approvata per il caso.

Criteri di escalation

Tratta come impatto ad alta priorità un errore che coinvolge piu siti, un servizio di autenticazione centrale, account break-glass, il secure channel di un DC o un aumento rapido di failure Kerberos. Un singolo account applicativo fallito puo essere un problema locale, ma deve comunque avere owner, timestamp, DC che ha risposto e test di conferma prima di proseguire.

La gravità non dipende solo dal numero di ticket falliti. Una failure su VPN aziendale, piattaforma di produzione, servizio sanitario, controllo industriale o gestione degli amministratori può essere critica anche con pochi eventi. Inserisci questa classificazione nel change record prima del reset.

Inventario di dominio e raccolta evidenze ripetibile

Usa una cartella di evidenze protetta e con accesso limitato. Il nome della cartella deve contenere dominio, change ID e timestamp, ma non informazioni riservate sull'incidente. L'esempio seguente raccoglie un baseline leggibile; non modifica Active Directory.

$Domain = "contoso.com"
$ChangeId = "CHG-000000"
$Timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
$EvidencePath = Join-Path $env:USERPROFILE "Documents\KRBTGT-$Domain-$ChangeId-$Timestamp"
New-Item -ItemType Directory -Path $EvidencePath -Force | Out-Null

$Pdc = (Get-ADDomain -Server $Domain).PDCEmulator
Get-ADDomain -Server $Domain | Format-List * |
	Out-File (Join-Path $EvidencePath "domain.txt")

Get-ADDomainController -Filter * -Server $Domain |
	Select-Object HostName, Site, IPv4Address, IsGlobalCatalog, OperationMasterRoles |
	Export-Csv (Join-Path $EvidencePath "domain-controllers.csv") -NoTypeInformation

Get-ADUser krbtgt -Server $Domain -Properties PasswordLastSet, msDS-KeyVersionNumber, whenChanged |
	Select-Object SamAccountName, PasswordLastSet, msDS-KeyVersionNumber, whenChanged, Enabled |
	Export-Csv (Join-Path $EvidencePath "krbtgt-before.csv") -NoTypeInformation

repadmin /replsummary | Out-File (Join-Path $EvidencePath "repadmin-replsummary-before.txt")
repadmin /showrepl * /errorsonly | Out-File (Join-Path $EvidencePath "repadmin-showrepl-before.txt")
dcdiag /e /q | Out-File (Join-Path $EvidencePath "dcdiag-before.txt")

Al termine, proteggi la cartella con ACL coerenti con il ticket e carica solo gli artefatti consentiti nel sistema di change. repadmin, dcdiag e gli export possono rivelare nomi di host, siti e topologia: non allegarli a canali pubblici o ticket accessibili a utenti non autorizzati.

Mappa dei DC e dei siti

Per ciascun DC scrivibile annota sito AD, subnet, connettività, replica in ingresso/uscita, stato DNS e owner locale. Una topologia hub-and-spoke richiede particolare attenzione: un reset effettuato sul PDC Emulator non prova che un site remoto abbia ricevuto il cambiamento.

Per i siti remoti con link intermittenti, definisci un orario di verifica e una persona reperibile. Non bypassare il problema rimuovendo il DC dall'inventario o eseguendo il secondo reset senza la prova di replica. Un DC fuori sync puo continuare a emettere o validare ticket in modo incoerente rispetto al dominio.

Se un Domain Controller è stato decommissionato ma resta nei metadati, trattalo come difetto AD da correggere prima del change. Non usare il reset KRBTGT per "ripulire" repliche o oggetti obsoleti.

Trust, domini e identità esterne

Elenca forest trust, external trust, shortcut trust e applicazioni che usano identità di altri domini. La rotazione della password KRBTGT è domain-scoped, ma un flusso di autenticazione cross-domain puo fallire o cambiare percorso se esistono problemi preesistenti di DNS, trust, selective authentication, SID filtering o tempo.

Prima della finestra, esegui un login e un accesso al servizio per ogni trust business-critical. Conserva il risultato come baseline. Se un test cross-domain non è disponibile, registra l'eccezione, il rischio e l'approvazione esplicita: non definire che il trust è sano dal solo stato della replica interna.

Gli account Entra, cloud-only e le applicazioni che non usano Kerberos nel dominio non sono test KRBTGT validi. Includili nel piano solo se dipendono anche da AD DS, per esempio tramite AD FS, sSSO (Seamless SSO con Kerberos Delegation), LDAP, VPN con RADIUS o servizi Windows integrati.

Calcolo e approvazione della finestra W

La formula $W$ deve essere trasformata in una decisione leggibile nel change, non lasciata come concetto teorico. Registra il valore effettivo di MaxTicketAge, il tempo massimo osservato per la replica inter-site, il margine scelto e chi ha approvato la somma.

Elemento	Esempio	Fonte dell'evidenza
MaxTicketAge	10 ore	GPO/RSOP applicato ai DC
Replica piu lenta osservata	45 minuti	repadmin, monitoraggio e site link
Margine operativo	2 ore	Change owner e SOC
$W$ approvato	12 ore	Change record

Non usare MaxRenewAge come tempo tra i reset. Il KDC conserva due chiavi KRBTGT proprio per gestire la transizione dei TGT, mentre la soglia pratica deve garantire la scadenza dei ticket firmati con la chiave precedente e la replica del primo cambiamento. Se policy locali o requisiti di business prevedono valori superiori, documenta il valore piu conservativo.

Quando la finestra attraversa un cambio data, fuso orario o periodo di ridotto presidio, registra gli orari in UTC e nell'ora locale del team operativo. Questo evita che il secondo reset venga eseguito prima dell'attesa effettiva per una conversione errata.

Checkpoint prima del secondo reset

Il checkpoint deve essere un incontro o un messaggio formalizzato, non una decisione implicita dell'operatore. Il change owner riceve almeno:

• ora del primo reset e ora minima consentita per il secondo;
• esito replica per ogni DC e qualsiasi eccezione risolta;
• confronto dei failure rate Kerberos prima/dopo;
• esito dei test prioritari per sito e applicazione;
• ticket service desk aperti, impatto e owner;
• raccomandazione esplicita: go, hold oppure no-go.

Hold non è un fallimento. E la scelta corretta quando i dati non permettono di separare un impatto del change da un problema già esistente. Durante un hold, conserva le evidenze, chiarisci la causa e rivaluta la finestra senza resettare di nuovo.

Validazione replica per Domain Controller

Un report sintetico aiuta a evitare la lettura selettiva dell'output. Lo script seguente consulta ogni DC scrivibile e registra il KVNO osservato; eseguilo prima, dopo il primo reset e dopo il secondo reset. Adatta l'autenticazione remota alla policy aziendale e non eseguire comandi di modifica all'interno del ciclo.

$Domain = "contoso.com"
$ExpectedKvno = (Get-ADUser krbtgt -Server $Domain -Properties msDS-KeyVersionNumber).msDS-KeyVersionNumber
$Results = foreach ($DomainController in Get-ADDomainController -Filter * -Server $Domain) {
	try {
		$Krbtgt = Get-ADUser krbtgt -Server $DomainController.HostName `
			-Properties PasswordLastSet, msDS-KeyVersionNumber, whenChanged -ErrorAction Stop

		[pscustomobject]@{
			DomainController = $DomainController.HostName
			Site = $DomainController.Site
			PasswordLastSet = $Krbtgt.PasswordLastSet
			Kvno = $Krbtgt.'msDS-KeyVersionNumber'
			ExpectedKvno = $ExpectedKvno
			MatchesExpected = $Krbtgt.'msDS-KeyVersionNumber' -eq $ExpectedKvno
			Status = "QuerySucceeded"
		}
	} catch {
		[pscustomobject]@{
			DomainController = $DomainController.HostName
			Site = $DomainController.Site
			PasswordLastSet = $null
			Kvno = $null
			ExpectedKvno = $ExpectedKvno
			MatchesExpected = $false
			Status = $_.Exception.Message
		}
	}
}

$Results | Sort-Object Site, DomainController | Format-Table -AutoSize
if ($Results.Where({ -not $_.MatchesExpected }).Count -gt 0) {
	throw "Stop: one or more writable DCs do not report the expected KRBTGT KVNO."
}

Un errore di query non è un esito neutro: equivale a una mancata prova. Se il comando non riesce contro un DC, verifica DNS, connettivita, privilegi e stato di replica. Solo dopo aver escluso un falso negativo tecnico puoi decidere, con il change owner, se la situazione richiede una finestra di recovery separata.

Il KVNO confrontato deve essere quello osservato sul dominio dopo il reset, non un valore scritto a mano in anticipo. In questo modo lo script rileva anche il caso in cui il primo reset non sia stato eseguito contro il dominio previsto o il comando sia fallito senza essere notato.

Matrice dei test funzionali

Un test deve avere un owner, un account, una destinazione e un risultato atteso. "Login riuscito" non e abbastanza per un'applicazione che usa ticket di servizio con SPN specifici o delegation.

Servizio	Account e origine	Azione	Evidenza di successo	Owner
File server	Utente standard, sito A	Aprire \\server.dominio\share via FQDN	Accesso e 4624 Kerberos sul target	Infrastructure
IIS SSO	Utente standard, sito B	Aprire URL HTTPS integrato	Nessun prompt; ticket HTTP in klist	Application
SQL	Account applicativo autorizzato	Connessione Integrated Security	Query di salute riuscita	DBA
VPN/VDI	Utente test non privilegiato	Nuova autenticazione	Sessione avviata, nessun loop credenziali	Workplace
Tier 0	Admin dedicato, PAW	Consolle e tool amministrativi	TGT e servizio amministrativo validi	AD owner

Esegui un test a freddo quando possibile: elimina i ticket locali, crea una nuova sessione e usa un percorso DNS supportato. Un test eseguito da un browser o client che ha una sessione lunga puo nascondere il fatto che il TGT non viene richiesto nuovamente.

Per IIS, SQL e file server annota gli SPN attesi, l'account che li possiede e il nome DNS usato nel test. Questa informazione accelera il triage: un KDC_ERR_S_PRINCIPAL_UNKNOWN tende a indicare un problema SPN/naming, non una ragione per ripetere il reset KRBTGT.

Triage dei failure Kerberos

La tabella non sostituisce la documentazione ufficiale o l'analisi degli eventi completi, ma offre una prima classificazione per evitare azioni distruttive durante la finestra.

Segnale	Ipotesi iniziale	Primo controllo	Azione vietata
4771 in aumento su molti client	Password, pre-authentication, clock skew o ticket stale	Failure code, tempo DC/client, account coinvolti	Resettare di nuovo KRBTGT
4768 assenti da un intero sito	DNS, rete, DC non raggiungibile o logging	Reachability DC, DNS e Security log locale	Dichiarare successo dal solo PDC
HTTP 401 dopo logon nuovo	SPN HTTP, app pool o browser zone	klist, SPN, log IIS e app pool	Cambiare policy Kerberos senza owner
SMB/SQL fallisce solo via alias	CNAME/SPN o naming non coerente	FQDN canonico e setspn -Q	Classificare come outage KRBTGT
Errori intermitenti tra siti	Replica, tempo, DNS site-aware o link WAN	repadmin, w32tm, DNS e site link	Eseguire secondo reset prima del triage

Esegui setspn -Q solo con il nome di servizio previsto e raccogli l'output nel ticket. Non modificare SPN nel mezzo della finestra senza owner applicativo e piano separato: una correzione non correlata distrugge la capacita di attribuire causa ed effetto.

$ServiceName = "HTTP/app.contoso.com"
setspn -Q $ServiceName

klist purge
klist get $ServiceName
klist tickets

w32tm /query /status
Resolve-DnsName app.contoso.com

L'output atteso e un ticket di servizio per lo SPN interrogato, risoluzione DNS coerente e una sorgente tempo sana. Se la query SPN restituisce duplicati o assenza di owner, apri un remediation change separato e non modificare l'oggetto in modo improvvisato durante la rotazione.

Monitoraggio rinforzato e riesame

Mantieni monitoring rinforzato per almeno un ciclo operativo rappresentativo: includi job notturni, backup, apertura giornaliera, elaborazioni batch e utenti di siti remoti. In ambienti con processi mensili o stagionali, dichiara il limite del periodo osservato e pianifica un riesame dopo quel processo.

Ogni alert deve riportare almeno DC, client o target, account, Event ID/failure code, timestamp UTC, servizio e correlazione con il change. Conta separatamente successi e failure perche una crescita del volume legittimo puo rendere fuorviante il solo conteggio assoluto.

Riesame dopo la chiusura

Al riesame verifica:

• nessun DC e tornato a errore di replica o ha mostrato variazioni KVNO inattese;
• i tassi di 4768, 4769, 4771, 4624 e 4625 sono spiegati e vicini alla baseline;
• gli owner hanno completato gli eventuali test differiti;
• i ticket del service desk correlati sono chiusi o hanno un piano di remediation;
• il team IR ha archiviato indicatori, decisioni e follow-up della compromissione iniziale.

La rotazione rimuove la validita della chiave KRBTGT precedente dopo la sequenza corretta; non dimostra da sola che un attaccante sia stato rimosso dai DC. Mantieni le attivita di containment, caccia alle minacce, revisione privilegiata e recovery definite dall'incident response plan.

Checklist finale

• Motivazione e scope per dominio approvati.
• Salute AD/DNS/SYSVOL e backup verificati prima del primo reset.
• Primo reset eseguito e KVNO replicato su tutti i DC scrivibili.
• Attesa $W$ conclusa con telemetria e test nella baseline.
• Secondo reset autorizzato, eseguito e replicato.
• Test Kerberos, servizi critici e siti AD completati.
• Evidenze archiviate, monitoraggio rinforzato attivo e change chiuso con owner.