• Guide, Sicurezza, Sistemi Operativi
• 2 Agosto 2026

Uno degli errori più comuni nella gestione di Active Directory consiste nell’utilizzare gli account amministrativi su workstation e server che non dovrebbero mai ospitare credenziali con privilegi elevati. È proprio da queste situazioni che hanno origine molti degli attacchi informatici più gravi.

Nella maggior parte dei casi gli attaccanti non prendono di mira direttamente i Domain Controller. Preferiscono compromettere un computer di un amministratore o un server membro, rubare le credenziali presenti in memoria e utilizzarle per spostarsi lateralmente fino a raggiungere gli account con privilegi più elevati. Tecniche come Pass-the-Hash e Pass-the-Ticket esistono da molti anni e continuano ancora oggi a rappresentare una delle principali minacce per gli ambienti Active Directory. Ne abbiamo parlato abbondantemente nella serie AD-ventures: La battaglia per la sicurezza di Active Directory – ICT Power

La difesa più efficace consiste nel non esporre mai le credenziali privilegiate su sistemi che potrebbero essere compromessi. È proprio questo il principio su cui si basa Active Directory Tiering, il modello introdotto da Microsoft per separare gli account amministrativi, i computer e le risorse in diversi livelli di attendibilità.

Nella figura sotto viene mostrato la rappresentazione della Cyber Attack Kill Chain. Dopo l’accesso iniziale all’infrastruttura, gli attaccanti cercano di ottenere la persistenza e di effettuare il movimento laterale (Lateral Movement) tra sistemi e account privilegiati fino a raggiungere le risorse di maggiore valore. L’obiettivo finale è l’accesso ai dati e la loro esfiltrazione. Il modello di Active Directory Tiering è progettato proprio per interrompere il movimento laterale, impedendo che le credenziali amministrative possano essere utilizzate per compromettere livelli di sicurezza superiori.

Figura 1: Rappresentazione della Cyber Attack Kill Chain

L’idea è tanto semplice quanto efficace: un amministratore deve utilizzare il proprio account privilegiato esclusivamente sui sistemi appartenenti allo stesso livello di sicurezza. In questo modo, anche se una workstation o un server dovessero essere compromessi, l’attaccante non potrebbe intercettare le credenziali utilizzate per amministrare i livelli superiori dell’infrastruttura.

È importante sottolineare che il tiering non è una funzionalità di Active Directory e nemmeno una soluzione che si installa con pochi clic. Si tratta di un modello di amministrazione che richiede una corretta organizzazione degli account, dei gruppi, delle workstation amministrative e delle procedure operative. Se implementato correttamente, contribuisce a limitare i movimenti laterali e rende molto più difficile la compromissione dell’intero dominio.

In questo articolo vedremo come implementare il modello di Active Directory Tiering utilizzando il progetto ufficiale Active Directory Tier Model pubblicato da Microsoft, che automatizza la creazione della struttura necessaria e costituisce un’eccellente base di partenza per realizzare un’infrastruttura amministrativa conforme alle best practice.

Il progetto Microsoft Active Directory Tier Model

Implementare un’infrastruttura basata sul modello di Active Directory Tiering richiede tempo e un’attenta pianificazione. È necessario creare una struttura di Organizational Unit (OU) dedicata, definire i gruppi di sicurezza, applicare le Group Policy, configurare le restrizioni di accesso e organizzare correttamente gli account amministrativi. Si tratta di un’attività tutt’altro che banale, soprattutto in ambienti di produzione già esistenti.

Per semplificare questo processo, Microsoft ha pubblicato il progetto Active Directory Tier Model, disponibile gratuitamente su GitHub. Non si tratta di uno script isolato, ma di un framework completo che automatizza la distribuzione della struttura necessaria per realizzare un’infrastruttura amministrativa conforme alle raccomandazioni ufficiali.

Il progetto crea automaticamente la gerarchia delle Organizational Unit, i gruppi di sicurezza, le Group Policy Object (GPO) e tutte le configurazioni necessarie per separare gli ambienti amministrativi in Tier 0, Tier 1 e Tier 2, seguendo le linee guida Microsoft. L’obiettivo non è soltanto organizzare Active Directory, ma soprattutto impedire che le credenziali amministrative vengano esposte su sistemi appartenenti a livelli di sicurezza inferiori.

Uno degli aspetti più interessanti del progetto è che è stato sviluppato seguendo un approccio idempotente. In pratica, lo stesso processo può essere eseguito più volte senza generare configurazioni duplicate o alterare gli oggetti già distribuiti. Questo consente di applicare modifiche, aggiornamenti e correzioni in modo controllato, rendendo la soluzione adatta anche ad ambienti enterprise nei quali la configurazione evolve nel tempo.

È importante sottolineare che il progetto non trasforma automaticamente un’infrastruttura esistente in un ambiente completamente protetto. Rimane infatti necessario classificare correttamente server, applicazioni, account amministrativi e workstation, decidendo a quale livello appartengono e adeguando le procedure operative dell’organizzazione. Gli script Microsoft forniscono la struttura e le configurazioni di base, ma il successo dell’implementazione dipende dalle scelte progettuali e dal rispetto delle regole del modello di tiering.

Figura 2: Modello di Active Directory Tiering proposto da Microsoft

Prerequisiti

Prima di procedere con l’implementazione è opportuno verificare che l’ambiente soddisfi alcuni prerequisiti. Il progetto Active Directory Tier Model è stato sviluppato per automatizzare la distribuzione della struttura organizzativa e delle configurazioni necessarie, ma richiede un’infrastruttura Active Directory già funzionante e correttamente configurata.

È necessario eseguire gli script con un account che disponga dei privilegi amministrativi necessari per creare Organizational Unit, gruppi di sicurezza, Group Policy Object (GPO) e gli altri oggetti previsti dal modello. Le operazioni devono essere eseguite da un sistema sul quale siano installati gli strumenti di amministrazione di Active Directory (RSAT) e il modulo GroupPolicy di PowerShell.

Il progetto è distribuito tramite GitHub e può essere scaricato utilizzando Git oppure come archivio ZIP dall’indirizzo https://github.com/microsoft/ActiveDirectoryTierModel. Una volta estratto il contenuto, troverete una struttura organizzata in cartelle che contiene gli script PowerShell, i modelli delle Group Policy e i file di configurazione utilizzati durante la distribuzione. Dopo aver scaricato il repository, troverete una struttura piuttosto articolata. Non lasciatevi però intimorire dal numero di cartelle e di script presenti: l’intero progetto è stato progettato in modo modulare, così da consentire una distribuzione controllata e ripetibile delle configurazioni. Ogni componente svolge un compito ben preciso e contribuisce alla creazione del modello di amministrazione a livelli.

La documentazione ufficiale è disponibile all’indirizzo https://microsoft.github.io/ActiveDirectoryTierModel/. Quest’ultima contiene una guida dettagliata all’implementazione, ma anche informazioni sull’architettura del progetto, sul funzionamento degli script e sulle metodologie utilizzate durante il deployment. Se desiderate approfondire ogni singolo componente, vi consiglio di consultarla prima di procedere.

Prima di eseguire qualsiasi script, vi consiglio di analizzare attentamente il contenuto del repository. Sebbene il progetto automatizzi gran parte della configurazione, è importante comprenderne il funzionamento e verificare quali modifiche verranno apportate al dominio. Come per qualsiasi intervento che coinvolga Active Directory, è buona norma testare la procedura in un ambiente di laboratorio prima di applicarla in produzione.

Quick Deployment Guide o Detailed Deployment Guide?

La documentazione Microsoft propone due percorsi differenti. Il Quick Deployment Guide è pensato per chi desidera distribuire rapidamente il modello ed è già familiare con il funzionamento del progetto. Il Detailed Deployment Guide, invece, descrive nel dettaglio ogni fase dell’implementazione e rappresenta il percorso migliore per comprendere la logica con cui vengono creati gli oggetti di Active Directory.

Nel corso di questo articolo seguiremo la Quick Deployment Guide.

Deployment

Il progetto Active Directory Tier Model richiede PowerShell 7, che introduce numerosi miglioramenti rispetto a Windows PowerShell 5.1 ed è la versione supportata dagli script Microsoft. Se PowerShell 7 non è già installato, è possibile utilizzare Windows Package Manager (winget) eseguendo il seguente comando da un prompt con privilegi amministrativi:

winget install Microsoft.PowerShell

Al termine dell’installazione sarà disponibile una nuova console PowerShell 7 (pwsh), che utilizzeremo per eseguire tutti gli script del progetto.

Figura 3: Installazione di PowerShell 7 tramite Windows Package Manager (winget)

Il progetto Active Directory Tier Model utilizza Pester, il framework di testing per PowerShell impiegato per verificare il corretto funzionamento degli script e dell’ambiente di deployment. Se il modulo non è già presente nel sistema, installatelo dalla PowerShell Gallery eseguendo il comando seguente in una console PowerShell 7 aperta con privilegi amministrativi:

Install-Module -Name Pester -MinimumVersion 5.0.0 -MaximumVersion 5.99.99 -Force -SkipPublisherCheck

L’opzione -Force installa automaticamente il modulo senza richiedere ulteriori conferme, mentre -SkipPublisherCheck evita il controllo della firma del publisher, come indicato nella documentazione ufficiale del progetto.

Figura 4: Installazione del modulo Pester dalla PowerShell Gallery

Dopo aver installato i prerequisiti, potete scaricare l’ultima versione del progetto Active Directory Tier Model direttamente dalla pagina delle Release del repository GitHub https://github.com/microsoft/ActiveDirectoryTierModel. Microsoft consiglia di utilizzare sempre l’ultima release disponibile, che include gli script aggiornati, le correzioni e la documentazione più recente.

Figura 5: Pagina delle Release del repository Active Directory Tier Model su GitHub

Dopo aver scaricato il pacchetto ZIP, estraetene il contenuto in una cartella locale. In questa guida utilizzeremo il percorso C:\ActiveDirectoryTierModel-main, che verrà richiamato nei comandi PowerShell eseguiti nei paragrafi successivi.

All’interno della cartella troverete gli script PowerShell, i moduli, i file di configurazione e la documentazione del progetto. Tra i file più importanti è presente Deploy-TierModel.ps1, lo script che verrà utilizzato per distribuire il modello di tiering nell’ambiente Active Directory.

Figura 6: Script di deployment, i moduli PowerShell, i file di configurazione e la documentazione necessari per implementare l’Active Directory Tier Model

Distribuzione del modello di Tiering

Una volta verificati i prerequisiti e preparata la cartella di lavoro, è possibile avviare il deployment del modello eseguendo lo script Deploy-TierModel.ps1.

Nel nostro ambiente il Domain Controller di riferimento è DC01.virtual.lab, pertanto il comando utilizzato è il seguente:

.\Deploy-TierModel.ps1 -FullDeployment -PreferredDc DC01.virtual.lab -ConfirmApply

Il parametro -FullDeployment esegue la distribuzione completa del modello, mentre -PreferredDc specifica il Domain Controller sul quale verranno effettuate le modifiche. L’opzione -ConfirmApply richiede una conferma esplicita prima di apportare qualsiasi modifica ad Active Directory, evitando esecuzioni accidentali.

Durante il deployment lo script verifica innanzitutto che tutti i prerequisiti siano soddisfatti e quindi procede automaticamente alla creazione dei componenti del modello nell’ordine corretto. Vengono create le Organizational Unit (OU), i gruppi di sicurezza, gli account di servizio, le deleghe sui contenitori di Active Directory, le Group Policy Object (GPO) e i template amministrativi ADMX necessari al funzionamento dell’infrastruttura.

Al termine dell’esecuzione l’ambiente Active Directory sarà predisposto per adottare il modello di amministrazione a livelli previsto dal progetto Microsoft. Perfetto!!

Nota: il parametro -FullDeployment non installa le funzionalità opzionali relative a MSA, gMSA, dMSA e Windows LAPS. Se il vostro ambiente utilizza queste tecnologie, è possibile abilitarne automaticamente la configurazione aggiungendo gli appositi parametri (-IncludeMsa, -IncludeGmsa, -IncludeDmsa e -IncludeWinLaps) al comando di deployment.

Figura 7 Esecuzione dello script Deploy-TierModel.ps1 con il parametro -FullDeployment

Verifica del deployment

Al termine della distribuzione è consigliabile eseguire un audit completo dell’ambiente per verificare che tutti i componenti del modello siano stati creati correttamente e che non siano presenti configurazioni non conformi.

A tale scopo il progetto mette a disposizione lo script Audit-TierModel.ps1, che confronta la configurazione di Active Directory con lo stato previsto dal modello.

Nel nostro ambiente il comando utilizzato è il seguente:

.\Audit-TierModel.ps1 -FullDeployment -PreferredDc DC01.virtual.lab

Lo script esegue una verifica completa degli oggetti distribuiti, controllando l’esistenza delle Organizational Unit, dei gruppi di sicurezza, delle Group Policy, delle deleghe e delle altre configurazioni implementate durante il deployment. Al termine dell’analisi viene segnalata l’eventuale presenza di configurazioni mancanti o modificate rispetto allo stato desiderato, consentendo di individuare rapidamente eventuali anomalie o modifiche introdotte manualmente.

È consigliabile eseguire questo controllo non solo al termine dell’installazione, ma anche periodicamente, per verificare che l’infrastruttura continui a rispettare il modello di sicurezza definito.

Figura 8: Esecuzione dello script Audit-TierModel.ps1, che verifica la conformità dell’infrastruttura Active Directory confrontando gli oggetti distribuiti con la configurazione prevista dal modello e segnalando eventuali differenze o configurazioni non conformi

L’audit può richiedere alcuni minuti. Durante l’esecuzione lo script controlla progressivamente tutti i componenti distribuiti, confrontandoli con la configurazione prevista dal modello.

Al termine viene visualizzato un riepilogo con l’esito della verifica. Nel nostro caso tutti i controlli sono stati completati con successo e lo stato complessivo risulta COMPLIANT, a conferma che la distribuzione è stata eseguita correttamente e che non sono state rilevate differenze rispetto alla configurazione prevista.

Figura 9: Risultato finale dello script Audit-TierModel.ps1

La struttura creata in Active Directory

Al termine del deployment, aprendo Active Directory Users and Computers è possibile osservare la nuova struttura organizzativa creata automaticamente dal framework. Come si può notare dalla figura sotto, il progetto non si limita a creare alcune Organizational Unit (OU), ma realizza un’infrastruttura completa progettata per separare le identità amministrative in base al livello di privilegio.

Sono presenti le OU dedicate ai server, ai dispositivi degli utenti, agli account utente, ai gruppi di sicurezza e ai gruppi di distribuzione, oltre alla struttura Tier Model Administration, che rappresenta il cuore del modello di amministrazione.

All’interno di quest’ultima trovano posto i tre livelli previsti dal modello Microsoft (Tier 0, Tier 1 e Tier 2). Ciascun livello dispone di contenitori dedicati per account amministrativi, gruppi, account di servizio e Privileged Access Workstations (PAW). Questa organizzazione consente di mantenere separate le identità privilegiate e di applicare criteri di sicurezza differenti in funzione del livello amministrativo.

La struttura include inoltre alcune OU dedicate alle attività operative, come le aree di staging e la Tier Model Computer Quarantine, utilizzata per isolare i dispositivi che non soddisfano i requisiti previsti dal modello.

Questa organizzazione costituisce la base sulla quale verranno applicate le Group Policy, le deleghe amministrative e le restrizioni di accesso che consentono di implementare correttamente il modello di Active Directory Tiering.

Figura 10: Struttura delle Organizational Unit creata automaticamente dal progetto Active Directory Tier Model

Oltre alla struttura delle Organizational Unit, il progetto crea automaticamente numerosi gruppi di sicurezza, organizzati in base ai tre livelli amministrativi del modello (Tier 0, Tier 1 e Tier 2).

Ogni gruppo è progettato per svolgere una funzione specifica e implementare il principio del minimo privilegio. Sono presenti gruppi dedicati agli amministratori dei diversi livelli, agli operatori, agli account di servizio, ai Privileged Access Workstations (PAW), ai server membri e alle attività di Domain Join, oltre ad altri gruppi utilizzati per applicare le deleghe amministrative e le restrizioni previste dal framework.

Uno degli aspetti più interessanti è che ogni gruppo è corredato da una descrizione dettagliata, che ne documenta chiaramente lo scopo e le autorizzazioni previste. Questo facilita la gestione dell’infrastruttura e consente agli amministratori di comprendere rapidamente il ruolo di ciascun gruppo senza dover consultare la documentazione del progetto.

Figura 11: Gruppi di sicurezza creati automaticamente dall’Active Directory Tier Model

Viene creato anche automaticamente un numero elevato di Group Policy Object (GPO), già organizzate e collegate alle rispettive OU.

Come è possibile osservare nella Group Policy Management Console (GPMC), le policy sono suddivise in base al livello amministrativo (Tier 0, Tier 1 e Tier 2) e alla tipologia di sistema da proteggere, ad esempio Domain Controller, Member Server e Privileged Access Workstation (PAW).

Le GPO implementano automaticamente molte delle configurazioni di sicurezza previste dal modello Microsoft, tra cui restrizioni per gli account amministrativi, configurazioni di Microsoft Defender, BitLocker, Credential Guard, AppLocker, criteri di auditing, impostazioni di sicurezza del sistema operativo e numerose altre configurazioni necessarie per ridurre la superficie di attacco.

Uno dei principali vantaggi del progetto è proprio quello di automatizzare la distribuzione di queste policy, evitando all’amministratore di dover creare manualmente decine di Group Policy e configurarle singolarmente. Rimane comunque possibile personalizzare le GPO in base alle esigenze della propria organizzazione, mantenendo la struttura proposta dal framework.

Figura 12: Group Policy create dopo il deployment dell’Active Directory Tier Model

Tra le policy più importanti troviamo quelle dedicate alle restrizioni sugli account amministrativi, che impediscono l’utilizzo di credenziali appartenenti a un livello di privilegio su sistemi di livello inferiore. In questo modo, ad esempio, un account Tier 0 non può autenticarsi su una workstation o su un server appartenente ai livelli inferiori, riducendo drasticamente il rischio di credential theft e lateral movement.

Il progetto distribuisce inoltre numerose GPO dedicate alla configurazione di Microsoft Defender, AppLocker, BitLocker, Credential Guard, Windows Firewall, criteri di auditing, impostazioni di sicurezza del sistema operativo e altre configurazioni raccomandate da Microsoft per la protezione delle infrastrutture Active Directory.

Figura 13: sempio di Group Policy Object (GPO) creata automaticamente dall’Active Directory Tier Model

Molte delle Group Policy distribuite dal framework utilizzano i Restricted Groups, una funzionalità di Windows che consente di gestire in modo centralizzato l’appartenenza ai gruppi locali dei computer appartenenti ai diversi tier.

In questo modo è possibile stabilire con precisione quali gruppi di Active Directory possono essere membri dei gruppi locali, come Administrators o Remote Desktop Users, impedendo che vengano aggiunti utenti o gruppi non autorizzati direttamente sui sistemi.

Nell’esempio mostrato nella figura sotto, la GPO Tier 0 Servers Account Restrictions configura il gruppo locale Administrators dei server appartenenti al Tier 0, consentendo l’accesso amministrativo esclusivamente agli account e ai gruppi previsti dal modello. Questo garantisce che i privilegi amministrativi rimangano coerenti con la struttura del tiering e riduce il rischio di modifiche manuali che potrebbero compromettere la sicurezza dell’infrastruttura.

Figura 14: Configurazione dei Restricted Groups all’interno della GPO

Dopo il deployment: i passaggi successivi

L’implementazione del framework rappresenta solo il punto di partenza. Gli script creano la struttura organizzativa, le Group Policy e i gruppi di sicurezza, ma non spostano automaticamente utenti, server e workstation nei rispettivi Tier.

Per rendere realmente efficace il modello è necessario procedere con la classificazione delle risorse dell’infrastruttura e adeguare le procedure amministrative dell’organizzazione.

In particolare dovete:

• identificare i sistemi Tier 0, come i Domain Controller, i server PKI, AD FS, Microsoft Entra Connect e tutti i sistemi che possono amministrare Active Directory;
• spostare server, workstation e account nelle Organizational Unit appropriate create dal framework;
• assegnare gli amministratori ai gruppi di sicurezza previsti dal modello, evitando l’utilizzo di account condivisi;
• predisporre le Privileged Access Workstations (PAW) da utilizzare esclusivamente per le attività amministrative;
• verificare l’applicazione delle Group Policy e testare le restrizioni di accesso previste dal modello;
• eseguire periodicamente lo script di audit per verificare che l’infrastruttura continui a essere conforme alla configurazione prevista.

Solo dopo queste attività il modello di Active Directory Tiering potrà fornire i benefici per cui è stato progettato, limitando l’esposizione delle credenziali privilegiate e riducendo il rischio di movimenti laterali all’interno dell’infrastruttura.

Figura 15: Tier 0 – Identity control plane

Figura 16: Tier 1 – Enterprise server and application management

Figura 17: Tier 2 – End-user account and device support

Attenzione: Implementare il modello di Active Directory Tiering in un’infrastruttura esistente da molti anni non è un’attività che può essere completata in poche ore. Nella maggior parte degli ambienti sono presenti account amministrativi utilizzati quotidianamente, server gestiti da team differenti, applicazioni legacy e procedure operative consolidate che difficilmente rispettano il modello di separazione dei privilegi.

Per questo motivo è consigliabile affrontare la migrazione in modo graduale. Dopo il deployment del framework è opportuno classificare le risorse, identificare gli account privilegiati, verificare le dipendenze applicative e pianificare lo spostamento di server, workstation e amministratori nei rispettivi Tier. Solo dopo un’accurata fase di test sarà possibile applicare progressivamente le restrizioni previste dal modello, riducendo il rischio di interruzioni operative.

Privileged Access Workstations (PAW)

Uno degli elementi fondamentali del modello di Active Directory Tiering è l’utilizzo delle Privileged Access Workstations (PAW), workstation dedicate esclusivamente alle attività amministrative. Ogni livello del modello deve disporre della propria workstation dedicata: una Tier 0 PAW per amministrare le risorse Tier 0, una Tier 1 PAW per i server e le applicazioni Tier 1 e una Tier 2 PAW per l’amministrazione delle workstation e il supporto agli utenti.

Questo requisito è essenziale perché la sicurezza del modello dipende anche dal dispositivo utilizzato dall’amministratore. Se un account Tier 0 viene utilizzato su una normale workstation o su un computer appartenente a un livello inferiore, le relative credenziali potrebbero essere esposte in un ambiente meno sicuro, annullando di fatto i benefici del tiering e consentendo a un attaccante di effettuare movimenti laterali.

Per questo motivo ogni attività amministrativa dovrebbe essere eseguita esclusivamente da una PAW appartenente allo stesso livello di sicurezza delle risorse amministrate, mantenendo così la separazione tra i diversi Tier e preservando il confine di sicurezza su cui si basa l’intero modello.

Conclusioni

Il modello Active Directory Tiering rappresenta una delle strategie più efficaci per proteggere gli account privilegiati e limitare i movimenti laterali all’interno di un’infrastruttura Active Directory. Separare amministratori, server, workstation e account di servizio in livelli di sicurezza distinti consente infatti di ridurre significativamente il rischio che una compromissione di un sistema meno protetto possa estendersi fino ai Domain Controller.

Il progetto Active Directory Tier Model pubblicato da Microsoft semplifica notevolmente questa attività, automatizzando la creazione della struttura di Organizational Unit, dei gruppi di sicurezza, delle Group Policy, delle deleghe amministrative e delle altre configurazioni necessarie per implementare il modello. In questo modo è possibile partire da una configurazione già allineata alle best practice Microsoft, riducendo i tempi di implementazione e il rischio di errori.

Naturalmente il deployment rappresenta solo il primo passo. Per ottenere i massimi benefici è necessario classificare correttamente utenti, server e workstation, utilizzare Privileged Access Workstations (PAW) per le attività amministrative e adottare procedure operative coerenti con il modello di tiering. Solo in questo modo la separazione dei livelli di sicurezza diventa realmente efficace.

Per maggiori informazioni vi rimando alla lettura della guida ufficiale AD DS Tier Model for Privileged Access Security in Windows Server | Microsoft Learn