Procedure di Ripristino di Domain Controller – Parte V

In questa serie di articoli affrontiamo vari scenari di perdita di un Domain Controller e le relative procedure per rimediarvi:

Proseguiamo nei nostri scenari di ripristino concentrandoci sui Domain Controller virtuali, che attualmente rappresentano la maggioranza delle installazioni in produzione, tanto che Microsoft stessa fornisce linee guida precise per garantire la coerenza e l’integrità del database di Active Directory durante il ripristino di un DC virtuale.

Doverose letture preliminari:

Disclaimer: Le informazioni tecniche fornite in questo articolo sono pubblicate a solo scopo illustrativo e non costituiscono garanzia implicita o esplicita di correttezza, completezza o idoneità all’uso in ambienti di produzione. Le procedure descritte devono essere adottate esclusivamente da personale qualificato, previa validazione in ambienti di test controllati. L’autore e l’editore non potranno in alcun caso essere ritenuti responsabili per danni diretti, indiretti, consequenziali, perdite di dati, interruzioni operative o altri effetti negativi derivanti dall’utilizzo, applicazione o interpretazione delle informazioni contenute nel presente articolo, anche laddove tali danni siano stati segnalati come potenziali. È responsabilità esclusiva del lettore garantire la conformità alle policy aziendali, alle normative vigenti (ad esempio, GDPR, ISO/IEC 27001) e alle best practice dei vendor ufficiali (ad esempio, Microsoft).

Ripristino di un Domain Controller virtuale da backup del System State

Microsoft raccomanda di eseguire regolarmente il backup del System State di un Domain Controller per poter effettuare un ripristino in caso di emergenza. Il System State, infatti, include sia i dati che i file di log di Active Directory ed anche il Registry, il volume di sistema e vari elementi importanti del sistema operativo e di eventuali servizi aggiuntivi (se presenti):

Componente Descrizione
Database Active Directory (NTDS.dit) Contiene tutti gli oggetti della directory AD (utenti, computer, gruppi, ecc.)
SYSVOL Condivisione (replicata tra tutti i DC del dominio) che contiene file critici per i GPO (Group Policy Objects) e gli script di logon
Registry Include configurazioni critiche di sistema, come servizi, driver, applicazioni e chiavi di sicurezza
Boot files File di avvio del sistema operativo (ad esempio, bootmgr, BCD, NTLDR), necessari per il caricamento del sistema
File di configurazione COM+ Contiene le configurazioni dei servizi COM+
Active Directory Certificate Services (AD CS) Se installato, viene incluso il contenuto di AD CS: certificati, chiavi private, configurazione CA, log
Cluster database Se il nodo è parte di un Failover Cluster, il System State include il database di configurazione del cluster

Come effettuare il backup del System State

Ecco come eseguire correttamente il backup del System State di un Domain Controller, utilizzando strumenti nativi di Windows Server (procedura valida a partire da Windows Server 2008).

Step 1: Installare la funzionalità Windows Server Backup

Avviare una sessione PowerShell con privilegi amministrativi ed eseguire il comando

Install-WindowsFeature Windows-Server-Backup

Step 2: Eseguire il backup

Importante! Il backup deve essere effettuato su un volume diverso da quello di sistema o su un disco esterno o su una share di rete: non è supportato il backup sullo stesso volume del sistema operativo.

Nella sessione PowerShell eseguire il comando

wbadmin start systemstatebackup -backupTarget:<destinazione> -quiet

Ad esempio:

wbadmin start systemstatebackup -backupTarget:\\192.168.1.20\Backups -quiet

Il backup del System State viene archiviato nella directory: <destinazione>\WindowsImageBackup\<nome_server>\.


Step 3: Verificare il backup

Per monitorare l’andamento della procedura di backup (eventualmente lanciato da uno script schedulato ed eseguito in background), eseguire il comando PowerShell

wbadmin get status


Come ripristinare un backup del System State

Per ripristinare correttamente il DC, è necessario avviarlo in DSRM (Directory Services Restore Mode).

IMPORTANTE!
Se si perde l’opportunità di accedere alla modalità DSRM durante l’avvio del sistema, spegnere immediatamente la VM prima che possa avviarsi completamente in modalità normale. L’avvio in modalità normale incrementa i USN (Update Sequence Number), anche se il DC è scollegato dalla rete.

L’Update Sequence Number è un numero progressivo utilizzato da Active Directory per tenere traccia delle modifiche apportate agli oggetti nel database della directory. Ogni controller di dominio mantiene un proprio contatore USN.

Un “USN rollback” tipicamente si verifica quando un DC virtuale viene ripristinato da una snapshot senza usare tecniche corrette di ripristino per Active Directory, oppure viene utilizzato un backup non autorevole. In tal caso, il controller “ripristinato” presenta un database di AD più vecchio, ma con un USN più alto o uguale rispetto a prima del ripristino. Di conseguenza, gli altri DC credono erroneamente che quel controller sia aggiornato, e non gli inviano le modifiche più recenti, causando inconsistenza nei dati di Active Directory.

Avviare la VM del DC e premere il tasto F5 per accedere al Windows Boot Manager.

Se il Windows Boot Manager non si apre e il DC inizia ad avviarsi in modalità normale, spegnere la VM per interrompere il processo e ripetere questo passaggio tutte le volte necessarie finché non si riesce ad accedere al Boot Manager.

Nel Windows Boot Manager, premere il tasto F8 per accedere alle opzioni avanzate di avvio (Advanced Boot Options).

Nel menu Advanced Boot Options, selezionare Directory Services Repair Mode, e premere Invio.

Effettuare il logon con credenziali amministrative.

Per ottenere dettagli sui backup disponibili, avviare una sessione PowerShell come Admin ed eseguire il comando:

wbadmin get versions

Prendere nota del Version identifier.


Per avviare il processo di ripristino del System State, eseguire il comando

wbadmin start systemstaterecovery -version:<version_identifier> -backupTarget:<percorso> -quiet

Ad esempio:

wbadmin start systemstaterecovery -version:06/07/2025-16:07 -backupTarget:\\192.168.1.20\Backups -quiet


Al termine, verrà richiesto il riavvio del sistema per applicare il ripristino.


Verifica della replica AD

Dopo il riavvio della VM, avviare una sessione PowerShell come Admin e verificare lo stato della replica con il comando:

repadmin /replsummary

Ripristino di un Domain Controller da una snapshot o da un backup a livello immagine dell’intera VM

Snapshot e VM-Generation ID

Il ripristino di un Domain Controller da snapshot in ambiente virtuale presenta problematiche specifiche, sia dal punto di vista della coerenza dei dati di Active Directory che della gestione della replica fra i DC.

Tradizionalmente, il ripristino di un DC da snapshot era fortemente sconsigliato a causa del rischio del succitato “USN rollback”, ovvero la possibilità che il database di Active Directory tornasse a uno stato precedente senza che gli altri DC ne fossero consapevoli, causando inconsistenze, perdita di dati e problemi di autenticazione e replica.

Negli ambienti virtualizzati moderni, sia Hyper-V che VMware e praticamente tutti gli hypervisor on-prem e cloud, supportano il VM-Generation ID (VMGenID), un identificatore presentato dall’hypervisor al sistema operativo della VM (introdotto da Microsoft a partire da Windows Server 2012) che le permette di rilevare se è stata ripristinata da una snapshot: è impostato al momento della creazione della VM e cambia solo in caso di un evento importante (un ripristino da snapshot, una clonazione, un failover, eccetera).

I DC tengono traccia del valore VMGenID e lo controllano ogni volta che il sistema viene avviato e prima di alterare il database di AD: se il valore VMGenID è stato modificato, il Domain Controller deduce che si è verificato un evento “critico”.

Nell’Event Log relativo ai Directory Services la presenza dell’evento con ID 2170 indica che è stata rilevata una modifica al VMGenID e che quindi è stata eseguita una procedura di ripristino o di clonazione della VM.

Quando il DC al proprio avvio rileva un cambiamento del VMGenID, vengono attivate automaticamente delle misure di protezione per garantire la coerenza e l’integrità di Active Directory.

Di fatto, il DC confronta il valore del VMGenID fornito dall’hypervisor con quello memorizzato localmente nell’attributo msDS-GenerationId del proprio database AD (non viene replicato agli altri controller): se i due valori non coincidono, il DC esegue le seguenti azioni:

  • Reset dell’Invocation ID: L’Invocation ID, che identifica un’istanza del database AD ed è utilizzato dai partner di replica per tracciare le modifiche, viene rigenerato. Il DC può quindi avviare una nuova sessione di replica, evitando problemi di “USN rollback” e assicurando che tutte le modifiche necessarie vengano replicate correttamente.
  • Rilascio del pool RID: Il pool di Relative Identifier, viene scartato e ne viene richiesto uno nuovo dal RID Master, prevenendo la possibilità di duplicazione di SID.
  • Aggiornamento dell’attributo msDS-GenerationId: Il nuovo valore di VMGenID viene scritto nell’attributo locale msDS-GenerationId del DC.

Nonostante queste salvaguardie, permangono alcune criticità:

  • Se si ripristinano contemporaneamente tutti i DC di un dominio da snapshot, la replica di SYSVOL può bloccarsi, poiché tutti i DC si troverebbero in modalità “non autorevole” e nessuno potrebbe fungere da sorgente autorevole per la replica.
  • Le modifiche apportate localmente a un DC dopo la creazione della snapshot e non replicate agli altri DC andranno perse definitivamente dopo il ripristino.
  • Infine, la snapshot viene conservata nello stesso ambiente di produzione dove si trova la VM da cui è stata creata: in caso di disastro a livello hardware, non sarà possibile effettuare alcun tipo di ripristino.

Utilizzo di tool di backup dedicati

Per proteggere e ripristinare correttamente un Domain Controller virtuale, è possibile utilizzare soluzioni di backup che siano application-aware, ossia in grado di interagire con i VSS (Volume Shadow Copy Services), garantire un salvataggio consistente e supportato dell’ambiente Active Directory e di gestire automaticamente secondo best practices le procedure di ripristino.

Il backup, a differenza della snapshot, è conservato in uno storage differente, preferibilmente off-site (anche per compliance normativa, si veda ad esempio la direttiva “NIS2”). In caso di disastro che renda inaccessibile lo storage di produzione e che arrivi a coinvolgere gran parte se non tutti i DC, sia a seguito di un guasto hardware che di un attacco informatico, da backup sarà quindi possibile ripristinare in tempi rapidi tutte le VM coinvolte.

Per approfondire questo tipo di scenario, vi rimando a questo video https://www.youtube.com/watch?v=kkBv7fZLNFo registrato in occasione dell’edizione estiva della POWERCON2024, in cui ho presentato le procedure per la protezione e il ripristino di Active Directory utilizzando Veeam Backup & Replication.

 

Nella sessione viene mostrato come sia possibile proteggere i Domain Controller e, soprattutto, ripristinarli in modo semplice, efficace e rapido in caso di necessità, evitando processi manuali e lunghi tempi di inattività attraverso due possibili procedure di ripristino:

  • L’Instant Recovery, per ripristinare un intero Domain Controller in pochi minuti, avviando la macchina virtuale direttamente dal file di backup
  • Il ripristino granulare di oggetti Active Directory (utenti, gruppi, OU, attributi) tramite Veeam Explorer for Microsoft Active Directory, ideale per recuperare modifiche o cancellazioni specifiche che non sono gestibili con il solo cestino di AD.

Conclusione

In questa ultima puntata della serie ci siamo dedicati al backup e ripristino del System State, all’utilizzo delle snapshot a livello di hypervisor come metodo di ripartenza e abbiamo introdotto il tema dell’importanza di utilizzare strumenti di backup per ambienti virtuali che minimizzino il tempo di ritorno in esercizio (RTO) e semplifichino il recupero di interi Domain Controller o di singoli oggetti AD.