Active Directory resta il cuore dell’identità digitale nella maggior parte delle infrastrutture enterprise, proprio per questo è anche uno degli obiettivi primari di qualsiasi attacco informatico evoluto. Compromettere AD significa, nella maggior parte dei casi, ottenere il controllo totale dell’ambiente.
La sicurezza di Active Directory non si costruisce con un singolo prodotto o una configurazione isolata, ma attraverso una serie di scelte architetturali coerenti, basate soprattutto sulla riduzione dei privilegi, sulla separazione dei ruoli e sulla protezione delle credenziali più sensibili.
In questo articolo analizziamo alcune delle best practice fondamentali per aumentare in modo concreto il livello di sicurezza di un dominio Active Directory moderno.
Enterprise Admin e Schema Admin: meno è meglio
I gruppi Enterprise Admins e Schema Admins rappresentano il livello di privilegio più alto in una forest Active Directory. Proprio per questo dovrebbero essere trattati come ruoli eccezionali, non come strumenti operativi quotidiani.
Le best practice prevedono che:
- Non esistano account permanenti membri di Enterprise Admins
- Schema Admins venga popolato solo temporaneamente, esclusivamente durante attività di modifica dello schema (ad esempio upgrade di prodotti che lo richiedono)
In condizioni normali, questi gruppi dovrebbero essere vuoti. L’assegnazione del ruolo deve avvenire:
- per un tempo limitato
- con account dedicati
- preferibilmente tramite processi controllati (change management, approvazioni, auditing)
Ridurre l’esposizione di questi privilegi significa abbassare drasticamente l’impatto di un’eventuale compromissione delle credenziali.
Il modello Tier 0 – Tier 1 – Tier 2
Il gruppo Domain Admins è necessario per l’amministrazione del dominio, ma è anche uno dei bersagli principali negli attacchi di tipo privilege escalation e lateral movement. Una delle regole più importanti è la seguente: un account Domain Admin non deve mai essere utilizzato per accedere ai client.
L’approccio corretto è quello del Tier Model:
- Tier 0: Domain Controller, AD, PKI, sistemi di identità
- Tier 1: server applicativi e infrastrutturali
- Tier 2: client e workstation utente
Gli account Domain Admin appartengono al Tier 0 e, al massimo, possono operare verso sistemi Tier 1. Devono invece essere bloccati esplicitamente:
- dall’accesso interattivo ai client
- dall’uso su workstation di amministrazione non dedicate
Questo isolamento riduce il rischio che un malware presente su un endpoint utente possa intercettare credenziali ad alto privilegio.
Gestione dei client: account dedicati e separazione netta
La gestione dei client (Tier 2) deve avvenire con utenze dedicate, progettate appositamente per questo scopo. Le caratteristiche fondamentali di questi account sono:
- Permessi amministrativi solo sui client
- Nessun diritto di accesso verso server o Domain Controller
- Nessuna appartenenza a gruppi privilegiati di dominio
Questa separazione è spesso sottovalutata, ma è cruciale, poiché i client sono per natura più esposti, impiegati per attività ad alto rischio come web browsing ed email, e rappresentano nella maggior parte degli incidenti il primo vettore di compromissione dell’ambiente.
Limitare il raggio d’azione degli account di gestione client impedisce che una compromissione locale si trasformi in un incidente a livello infrastrutturale.
La realtà dei fatti dice però che questo approccio può essere molto scomodo per una gestione quotidiana, quindi avere un livello quantomeno verso il “2-1” è un ottimo punto di partenza ed aiuta a mitigare i rischi di sicurezza.
LAPS: gestione sicura delle password locali
Le password locali degli account amministrativi sono storicamente una delle debolezze principali negli aLa gestione delle password degli account amministrativi locali è storicamente uno dei punti più deboli negli ambienti Windows. L’utilizzo della stessa password su più sistemi, spesso per comodità operativa, espone l’infrastruttura a tecniche di attacco estremamente efficaci, come il credential dumping e il pass-the-hash, che consentono a un attaccante di spostarsi rapidamente da un sistema all’altro.
Local Administrator Password Solution (LAPS) nasce proprio per eliminare questo problema alla radice, introducendo un modello in cui ogni macchina dispone di una password locale univoca, generata in modo automatico, ruotata periodicamente e accessibile solo a soggetti autorizzati. In questo modo, anche in caso di compromissione di un singolo endpoint, l’attaccante non può riutilizzare quella credenziale per propagarsi all’interno del dominio.
Dal punto di vista architetturale, LAPS consente di:
- generare password complesse e non riutilizzabili
- automatizzarne la rotazione secondo criteri definiti
- eliminare la necessità di conoscere o distribuire manualmente le credenziali locali
- ridurre drasticamente il rischio di lateral movement
Tradizionalmente, la password dell’account amministrativo locale viene salvata in Active Directory, all’interno di attributi protetti dell’oggetto computer, con ACL che consentono l’accesso solo a gruppi o ruoli specifici. Questo approccio è già di per sé sicuro, a patto che i permessi siano configurati correttamente e che l’accesso venga tracciato.
Negli scenari più moderni, tuttavia, LAPS può essere integrato anche con Microsoft Entra, consentendo il salvataggio e la gestione delle password direttamente nel servizio di identità cloud. Questa modalità risulta particolarmente utile in contesti:
- Ibridi
- Cloud Native
- Dispositivi Microsoft Entra joined o gestiti tramite Intune
L’integrazione con Entra permette di applicare controlli di accesso avanzati, come Conditional Access e auditing centralizzato, migliorando ulteriormente la governance delle credenziali locali e allineando la gestione degli endpoint alle strategie di sicurezza cloud-native.
La chiave KRBTGT: il pilastro invisibile di Kerberos
La password dell’account KRBTGT è uno degli elementi più critici e sensibili di un dominio Active Directory. È la chiave utilizzata dal servizio Kerberos per firmare e cifrare i Ticket Granting Ticket (TGT), ovvero i ticket che consentono agli utenti di autenticarsi e ottenere accesso alle risorse di dominio.
Proprio per questo motivo, la compromissione della password KRBTGT rappresenta uno degli scenari peggiori in assoluto: un attaccante in possesso di questa chiave può generare Golden Ticket, impersonare qualsiasi identità — inclusi Domain Admin ed Enterprise Admin — e ottenere un accesso persistente e difficilmente rilevabile all’intera infrastruttura.
Microsoft raccomanda da tempo la rotazione periodica della password KRBTGT, mentre alcune linee guida di sicurezza più stringenti, come le STIG, suggeriscono un intervallo massimo di 180 giorni. Tuttavia, in ambienti ad alta criticità, la rotazione dovrebbe essere valutata non solo su base temporale, ma anche in funzione degli eventi di sicurezza.
Un aspetto spesso sottovalutato è che qualsiasi account privilegiato che abbia avuto la possibilità di generare Golden Ticket, anche solo temporaneamente, rappresenta un rischio finché la password KRBTGT rimane invariata. Se un utente con privilegi elevati lascia l’organizzazione o viene disabilitato, ma in precedenza ha potuto operare in un contesto “trusted”, eventuali ticket generati in quel periodo potrebbero continuare a essere validi.
In questi scenari, la mancata rotazione della KRBTGT può consentire a un attaccante di:
- mantenere accesso persistente al dominio
- aggirare i controlli di autenticazione standard
- operare indisturbato anche dopo la revoca delle credenziali ufficiali
Per questo motivo, una best practice avanzata consiste nel resettare la password KRBTGT ogni volta che un account con privilegi critici viene dismesso o compromesso, non limitandosi a una semplice rotazione periodica.
La rotazione della password KRBTGT deve essere eseguita con attenzione. La procedura corretta prevede due reset distinti, separati dal tempo necessario affinché la replica avvenga correttamente tra tutti i Domain Controller.
Il doppio reset è fondamentale per invalidare completamente eventuali ticket Kerberos già emessi. Tuttavia, è importante evitare un errore comune e potenzialmente impattante: eseguire due reset consecutivi in rapida successione, prima che la replica sia completata.
Un reset doppio troppo ravvicinato può infatti causare:
- invalidazione dei ticket ancora legittimi
- interruzioni nell’accesso ai server e ai servizi
- problemi di autenticazione su applicazioni che dipendono da Kerberos
La procedura deve quindi essere pianificata, monitorata e documentata, tenendo conto dei tempi di replica dell’infrastruttura e delle dipendenze applicative.
La gestione corretta della password KRBTGT non è solo una misura di hardening, ma un vero e proprio meccanismo di contenimento post-compromissione. In caso di incidente, rappresenta uno degli strumenti più efficaci per ripristinare la fiducia nel dominio e interrompere accessi persistenti invisibili ai controlli tradizionali.
Conclusioni
Mettere in sicurezza Active Directory significa prima di tutto ridurre i privilegi, non aumentarli. Ogni permesso superfluo rappresenta una superficie di attacco in più.
Limitare i ruoli più critici, separare nettamente gli ambiti operativi, proteggere le credenziali locali e gestire correttamente componenti chiave come KRBTGT non sono attività opzionali: sono prerequisiti per un dominio resiliente.
Active Directory è ancora oggi una tecnologia solida e affidabile, ma solo se amministrata con disciplina, consapevolezza e una visione moderna della sicurezza.