Ripristino e recupero di un controller di dominio locale danneggiato

Quando un controller di dominio si corrompe o viene ripristinato in modo errato, il timore è enorme: Gli accessi falliscono, le GPO smettono di essere applicate e la replica si interrompe quasi senza alcun indizio.La buona notizia è che esistono procedure chiare per il ripristino di un controller di dominio fisico o virtuale, a condizione che vengano rispettati i metodi di backup e ripristino standard.

Negli ambienti Windows Server moderni, il ripristino di un controller di dominio richiede una buona comprensione di concetti quali: stato del sistema, ripristino autorevole/non autorevole, rollback di SYSVOL, DFSR/FRS e USNSe questi problemi vengono affrontati frettolosamente o con strumenti di imaging incompatibili, il risultato può essere una selva piena di incongruenze silenziose molto difficili da diagnosticare.

Perché è fondamentale proteggere e ripristinare correttamente un controller di dominio

Active Directory è il cuore dell'autenticazione e dell'autorizzazione in un dominio Windows.Contiene informazioni su utenti, computer, gruppi, relazioni di fiducia, criteri di gruppo, certificati e altri elementi critici. Queste informazioni risiedono principalmente nel database. Ntds.dit, i file di registro e la cartella associati VOL.SIST, tra gli altri componenti che costituiscono il cosiddetto “stato del sistema”.

Lo stato del sistema comprende, tra le altre cose, File di registro e dati di Active Directory, Registro di sistema di Windows, volume di sistema, SYSVOL, database dei certificati (se esiste un'autorità di certificazione), metabase di IIS, file di avvio e componenti protetti del sistema operativo.Pertanto, qualsiasi strategia seria di continuità operativa deve includere backup regolari dello stato del sistema di ciascun data center.

Quando si verifica un effettivo danneggiamento del database di Active Directory, un grave errore di replica o un problema con permessi su VOL.SISTIl controller di dominio potrebbe interrompere l'elaborazione delle query, non riuscire ad avviare i servizi di Active Directory o innescare errori a cascata in tutta la foresta. In questi casi, Un intervento rapido e adeguato fa la differenza tra un incidente grave e un disastro prolungato..

Prima di tentare un ripristino, è fondamentale distinguere tra un problema reale del database e guasti più comuni. Molto spesso, La causa risiede nel DNS, nelle modifiche di rete, nei firewall o nelle rotte modificate con strumenti come comando netshPertanto, è consigliabile escludere prima questi fattori prima di intervenire sul database di AD.

Strumenti di base per la diagnostica e il controllo della replica

In caso di sintomi di corruzione o errori di replica, il primo passo sensato è verificare lo stato dell'ambiente utilizzando strumenti nativi. DCDiag, Repadmin, ReplMon (nelle versioni precedenti) e il Visualizzatore eventi Sono i vostri migliori alleati prima di prendere in considerazione restauri invasivi.

Con DCDiag Viene eseguito un controllo generale di tutti i controller di dominio, al fine di identificare eventuali problemi relativi alla replica, al DNS, ai servizi AD DS, ecc. Repadmin Consente di visualizzare lo stato della replica, i partner di replica, le filigrane USN e di rilevare gli oggetti persistenti. Nelle versioni precedenti di Windows, Sostituzione Offriva una visualizzazione grafica degli errori di replica all'interno del dominio.

Oltre a questi strumenti, è essenziale esaminare il Visualizzatore eventi per "Servizi di directory" e "Replica DFS". Eventi come il 467 e il 1018 indicano un effettivo danneggiamento del database., mentre gli eventi 1113/1115/1114/1116 si riferiscono all'attivazione o alla disattivazione della replica di input/output.

Se un DC sospetto deve essere temporaneamente isolato per impedirgli di diffondere la corruzione, possiamo Disabilita la replica in entrata e in uscita con Repadmin:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

Per ripristinare la replica normale, è sufficiente rimuovere queste opzioni:

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Backup dello stato del sistema supportati sui controller di dominio

Per poter recuperare un DC con garanzie, è essenziale avere Backup dello stato del sistema eseguiti utilizzando strumenti compatibili con Active DirectoryQuesti strumenti utilizzano le API di backup e ripristino di Microsoft e il servizio Volume Shadow Copy (VSS) in modo supportato.

Tra le soluzioni più comuni ci sono Backup di Windows Server, soluzioni di terze parti integrate con VSS (come NAKIVO, Backup Exec e altre)o servizi più vecchi come Ntbackup in Windows 2000/2003. In tutti i casi, devono rispettare le API di Active Directory per garantire la coerenza del database e delle sue repliche dopo il ripristino.

Windows Server 2012 e versioni successive includono un'importante novità: ID di generazione di Hyper-V (GenID)Questo identificatore consente a un controller di dominio virtuale di rilevare che il suo disco è stato ripristinato a un punto precedente nel tempo. Quando ciò si verifica, AD DS genera un nuovo InvocationID e tratta la situazione come se fosse stata ripristinata da un backup riuscito.notificando i suoi partner di replica, consentendo così una riscrittura sicura senza incorrere in un rollback USN.

È essenziale rispettare il vita della lapideQuesto valore indica per quanto tempo è possibile utilizzare un backup dello stato del sistema senza rischiare di reintrodurre oggetti eliminati molto tempo fa. In genere, nelle versioni moderne, il periodo è di 180 giorni, ed è consigliabile eseguire backup almeno ogni 90 giorni per mantenere un margine di sicurezza sufficiente.

Metodi non autorizzati che causano inversioni USN

Una delle cause più pericolose di incoerenze silenziose in Active Directory è la Riorganizzazione della Marina statunitenseQuesta situazione si verifica quando il contenuto del database AD viene ripristinato utilizzando una tecnica non supportata, senza che l'InvocationID venga ripristinato o che i partner di replica vengano notificati.

Lo scenario tipico è quello di avviare un DC da un immagine del disco o un'istantanea di una macchina virtuale scattata in passatosenza utilizzare un ripristino di sistema compatibile. Oppure copia direttamente il file Ntds.dit, usa programmi di imaging come Ghost, avvia da un mirror del disco danneggiato o riapplica uno snapshot di archiviazione a livello di array.

In questi casi, il controller di dominio continua a utilizzare lo stesso InvocationID di prima, ma il suo Il contatore locale della USN va all'indietroGli altri DC ricordano di aver ricevuto modifiche fino a un USN elevato, quindi quando il DC ripristinato tenta di inviare nuovamente USN già riconosciuti, I loro partner credono di essere al passo con i tempi e smettono di accettare cambiamenti concreti.

Il risultato è che certe modifiche (ad esempio, creazione utenti, modifiche password, registrazione dispositivi, modifiche appartenenza a gruppi, nuovi record DNSQuesti errori non vengono mai replicati dal controller di dominio ripristinato al resto della rete, ma gli strumenti di monitoraggio potrebbero non segnalarli in modo evidente. Si tratta di un guasto silenzioso estremamente pericoloso.

Per rilevare queste situazioni, i driver di Windows Server 2003 SP1 e versioni successive registrano le Evento Servizi di directory 2095 Quando viene rilevato un DC remoto che invia USN già riconosciuti senza una modifica in InvocationID, il sistema Mette in quarantena il controller di dominio interessato, sospende Netlogon e impedisce ulteriori modifiche. che non è stato possibile replicare correttamente.

Come ulteriore prova forense, può da consultare nel Registro il tasto HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters e il valore Dsa non scrivibileSe questo valore è impostato (ad esempio, 0x4), indica che il DC è stato messo in uno stato di non scrittura dal rilevamento dell'inversione USN. La modifica manuale di questo valore per "correggerlo" non è assolutamente supportata. e lascia il database in uno stato permanentemente incoerente.

Strategie generali in caso di danneggiamento o ripristino di un controller di dominio

La procedura da seguire quando si ha a che fare con un controller di dominio danneggiato o ripristinato in modo errato dipende da diversi fattori: Numero di controller di dominio nel dominio/foresta, disponibilità di copie valide dello stato del sistema, presenza di altri ruoli (FSMO, CA, catalogo globale) e ambito temporale del problema.

Se ci sono altri DC sani nel dominio e Non sono presenti dati critici univoci sul controller di dominio danneggiato.L'opzione più rapida e pulita è solitamente quella di rimuovere il controller di dominio e ricrearlo. Tuttavia, se è l'unico controller di dominio o se ospita ruoli e dati sensibili, sarà necessario un ripristino più accurato (autoritativo o non autoritativo).

In termini generali, le opzioni sono:

• Declassare forzatamente il controller di dominio danneggiato e rimuoverlo dal dominio., seguito dalla pulizia dei metadati e, se del caso, da una nuova promozione.
• Ripristina da un backup valido dello stato del sistema, sia in modalità autorevole che non autorevole.
• Ricreare il controller di dominio da un altro utilizzando IFM (Install From Media).quando non è presente una copia recente ma ci sono altri controller di dominio corretti.
• Utilizzo di uno snapshot VHD di un controller di dominio virtuale, applicando i passaggi aggiuntivi per contrassegnare il database come ripristinato da backup (Database ripristinato da backup = 1) e assicurandosi che venga generato un nuovo InvocationID.

Se si sospetta chiaramente un rollback USN (ad esempio, dopo aver ripristinato una VM da uno snapshot senza seguire le best practice) e viene visualizzato l'evento 2095, la linea d'azione più sensata è solitamente Rimuovi quel controller di dominio dal servizio e non tentare di "ripararlo" in loco., a meno che non sia possibile ripristinare un backup dello stato del sistema supportato effettuato prima del rollback.

Declassamento forzato e pulizia dei metadati

Quando un controller di dominio è così danneggiato da non poter essere declassato normalmente, oppure è stato ripristinato in modo errato e si desidera impedirne la diffusione di problemi, è possibile ricorrere a un retrocessione forzata.

Nelle versioni precedenti, questa operazione veniva eseguita con dcpromo /rimozione forzataQuali Rimuovere il ruolo AD DS senza tentare di replicare le modifiche al resto della foresta.Negli ambienti moderni la procedura guidata è cambiata, ma il concetto rimane lo stesso: rimuovere il controller di dominio problematico dalla topologia di Active Directory senza che partecipi a ulteriori replicazioni.

Dopo un downgrade forzato, è obbligatorio eseguire un comando da un controller di dominio funzionante. pulizia dei metadati utilizzando lo strumento NtdsutilQuesto processo rimuove tutti i riferimenti al DC eliminato (oggetti Impostazioni NTDS, riferimenti DNS, ecc.) dal database AD, in modo che non rimangono resti "fantasma" che possano confondere la replicazione.

Se il controller degradato aveva ruoli FSMO (PDC Emulator, RID Master, Schema Master, ecc.), sarà necessario trasferisce o assume tali ruoli su un altro controller di dominio prima o dopo la retrocessione, a seconda della situazione. Successivamente, il sistema operativo può essere reinstallato su quel server e quest'ultimo può essere promosso nuovamente a controller di dominio pulito.

Ripristino non autorevole vs. ripristino autorevole in Active Directory

Quando è disponibile una copia valida dello stato del sistema, il ripristino di Active Directory può essere effettuato in due modi: non autorevole e autorevoleComprendere la differenza è fondamentale per non perdere i cambiamenti recenti o per non replicare dati obsoleti.

in un restauro non autorevoleIl CC viene riportato a un punto precedente, ma una volta avviato, Gli altri controller di dominio sono considerati il ​​riferimentoIn altre parole, dopo l'avvio, il DC ripristinato richiede la replica in entrata e aggiorna il suo database con tutte le modifiche mancanti dagli altri DC. Questa opzione è ideale quando Ci sono altri soggetti di controllo sani e vogliamo che quello ristabilito raggiunga il loro livello..

in un restaurazione autoritariaTuttavia, è esplicitamente affermato che I dati ripristinati sono quelli che dovrebbero prevalere. rispetto a quanto hanno gli altri DC. Ciò significa che, dopo il ripristino, gli oggetti recuperati avranno un numero di versione più alto per forzarne la replica da quel DC al resto del dominio. È la scelta appropriata quando Abbiamo cancellato accidentalmente oggetti o unità organizzative, oppure desideriamo ripristinare il contenuto di SYSVOL e GPO a uno stato precedente e replicarlo..

Un dettaglio importante è che il ripristino autorevole non deve necessariamente riguardare l'intero database. Con l'utilità Ntdsutil È possibile contrassegnare come autorevoli singoli oggetti, sottostrutture (ad esempio, un'unità organizzativa) o l'intero dominio. Ciò offre una notevole flessibilità, ad esempio, recupera solo un utente, un gruppo, un'unità organizzativa o il sottoalbero dc=mycompany,dc=local.

Procedura generale per il ripristino dello stato del sistema in un DC

Lo schema di base per ripristinare lo stato del sistema di un controller di dominio (fisico o virtuale) con strumenti compatibili è sempre simile: Avviare in modalità di ripristino dei servizi di directory (DSRM), ripristinare utilizzando lo strumento di backup e riavviare.

In sintesi, i passaggi tipici per un controller di dominio virtuale sarebbero:

1. Avvia la macchina virtuale tramite Gestione avvio di Windows. (di solito premendo F5/F8 durante l'avvio). Se la macchina virtuale è gestita da un hypervisor, potrebbe essere necessario mettere in pausa la macchina per acquisire la pressione del tasto.
2. Nelle opzioni di avvio avanzate, selezionare modalità di ripristino dei servizi di directory (Modalità di ripristino dei servizi di directory). Questa modalità avvia il server senza montare il database di Active Directory in modo funzionale.
3. Accedi con l'account amministratore di DSRM. definito durante la promozione iniziale del DC (non con un account di amministratore di dominio standard).
4. Eseguire lo strumento di backup Utilizzare (Windows Server Backup, NAKIVO o altri programmi compatibili) e scegliere di ripristinare lo stato del sistema al punto di backup desiderato.
5. Completa la procedura guidata di ripristino e Riavviare il controller di dominio in modalità normale.In un ripristino non autorevole, il server avvierà la replica per sincronizzarsi con gli altri controller di dominio.

Quando parliamo di prodotti di backup di terze parti, come Backup e replica NAKIVOLa sua modalità "compatibile con le app" è in grado di riconoscere che la macchina da ripristinare è un DC e regolare automaticamente il processo per preservare la coerenza di ADNella maggior parte degli scenari con più controller, un ripristino completo in modalità non autorevole è sufficiente.

Ripristino autorevole con Ntdsutil

Se si desidera che le modifiche apportate al controller di dominio ripristinato abbiano la precedenza sulle altre, è necessario aggiungere un passaggio extra dopo il ripristino non autorevole: utilizzare Ntdsutil per contrassegnare gli oggetti come autorevoli.

Il flusso semplificato sarebbe il seguente:

1. Ripristina lo stato del sistema nel modo standard e lascia il server ancora in Modalità DSRM (Non riavviare ancora in modalità normale).
2. Aprire un Prompt dei comandi con privilegi elevati e corri ntdsutil.
3. Attiva l'istanza AD con attivare l'istanza ntds.
4. Entrando nel contesto del restauro autorevole con ripristino autorevole.
5. Usa comandi come restore object <DN_objeto> o restore subtree <DN_subarbol>, dove DN è il nome distinto dell'oggetto o del sottoalbero da ripristinare in modo autorevole.
6. Conferma la transazione e, una volta completata, Riavviare il controller di dominio in modalità normale. in modo che gli oggetti contrassegnati vengano replicati con priorità rispetto al resto del dominio.

Questo tipo di restauro richiede grande cautela. Se l'intero dominio viene ripristinato in modo autorevole e il backup è vecchioEsiste il rischio di perdere modifiche legittime apportate dopo il backup (ad esempio, creazione di utenti, modifiche delle password o modifiche ai gruppi). Pertanto, è prassi comune limitare i ripristini autorevoli ai soli oggetti o alberi strettamente necessari.

Ripristino e recupero di SYSVOL (FRS vs DFSR)

SYSVOL è un componente chiave del controller di dominio: Contiene script di avvio, criteri di gruppo, modelli di sicurezza e altre risorse condivise essenziali.Un errore nelle autorizzazioni, il danneggiamento dei file o problemi di replica possono rendere gli oggetti Criteri di gruppo (GPO) inutilizzabili o causare comportamenti anomali nei client.

A seconda della versione di Windows Server e dello stato della migrazione, SYSVOL può essere replicato da FRS (Servizio di replica file) oppure DFSR (Replica distribuita del file system)La procedura per un ripristino autorevole di SYSVOL varia a seconda di quale dei due sia in uso.

Per determinarlo, è possibile controllare la chiave nel Registro di sistema. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateSe questa sottochiave esiste e il suo valore è 3 (ELIMINATO), si sta utilizzando DFSR. Se non esiste o il suo valore è diverso, ci troviamo in un ambiente che utilizza ancora FRS.

Negli ambienti con FRS, il ripristino autorevole di SYSVOL di solito comporta la regolazione del valore Bandiere di segnalazione en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process a un valore specifico (ad esempio, 212 decimale / 0xD4 esadecimale) per indicare che questo DC è la fonte autorevole.

Se SYSVOL viene replicato da DFSR, il processo è un po' più elaborato: comporta l'utilizzo ADSIEdit per modificare gli oggetti di sottoscrizione SYSVOL (attributi msDFSR-abilitato y Opzioni msDFSR) sul DC autorevole e sugli altri, forzare la replica AD, eseguire dfsrdiag pollad e confermare nel registro eventi la comparsa di eventi 4114, 4602, 4614 e 4604 che certificano che SYSVOL è stato inizializzato e replicato correttamente.

Ripristino dei controller di dominio virtuali da VHD

Negli ambienti virtualizzati è molto comune avere File VHD/VHDX dei controller di dominioSe non si dispone di un backup dello stato del sistema ma si possiede un VHD "vecchio" funzionante, è possibile montare un nuovo controller di dominio da tale disco, sebbene sia necessario farlo con molta attenzione per evitare di causare un rollback USN.

La raccomandazione è Non avviare direttamente quella macchina virtuale in modalità normale.Invece, dovresti avviare dal VHD precedente in DSRMApri l'Editor del Registro di sistema e vai a HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersLì è consigliabile controllare il valore Conteggio dei restauri DSA precedenti (se esiste) e, soprattutto, creare un nuovo valore DWORD (32 bit) chiamato Database ripristinato da backup con valore 1.

Selezionando questo valore, ad Active Directory viene comunicato che il database è stato ripristinato da un backup, il che forza generazione di un nuovo InvocationID all'avvio in modalità normaleIn questo modo, gli altri controller di dominio lo interpretano come una nuova istanza e regolano correttamente i propri watermark di replica, impedendo il rollback USN.

Dopo aver riavviato il DC in modalità normale, è consigliabile controllare il Visualizzatore eventi, in particolare il registro di servizi di directory, cercando il Evento 1109Questo evento conferma che l'attributo InvocationID del server è cambiato e visualizza sia il vecchio che il nuovo valore, nonché l'USN più alto al momento del backup. Inoltre, il valore di Conteggio dei restauri DSA precedenti Avrebbe dovuto essere aumentato di uno.

Se questi eventi non compaiono o il conteggio non aumenta, è necessario controllare le versioni del sistema operativo e i Service Pack, poiché Alcuni comportamenti di ripristino dipendono da patch specificheIn ogni caso, è sempre consigliabile lavorare su una copia del file VHD originale, conservandone una versione integra nel caso in cui il processo debba essere ripetuto.

Scenari pratici e ulteriori raccomandazioni

In pratica, i problemi di corruzione o di restauri impropri si presentano spesso in contesti quotidiani: Modifiche manuali delle autorizzazioni in SYSVOL, tentativi di aggiornare i modelli ADMX/ADML, modifiche ai GPO non replicateecc. È relativamente facile causare incoerenze se le cartelle condivise vengono modificate manualmente, come ad esempio SYSVOL\Policies senza rispettare la replicazione.

Nel caso di un controller di dominio primario con replica interrotta (sia dati AD che SYSVOL) e messaggi di monitoraggio del tipo "Il database è stato ripristinato utilizzando una procedura non supportata. Possibile causa: rollback USN.", la cosa prudente da fare è:

• Verificare con dcdiag y repadmin l'entità degli errori e la presenza di "oggetti persistenti".
• Controlla l'evento 2095 e il valore Dsa non scrivibile nel Registro.
• Valutare se è possibile rimuovi quel DC e ricostruiscilo (Se sono presenti tre o più altre cellule dendritiche sane, questa è solitamente l'opzione migliore).
• Se è l'unico DC o critico, solleva una ripristino dello stato del sistema da un backup compatibile, idealmente recente e risalente al periodo di conservazione dei dati.

Nei domini con più controller, si raccomanda vivamente che i controller di dominio siano il più possibile "puri": senza ruoli aggiuntivi o dati utente localiIn questo modo, se uno dei controller di dominio si guasta o si corrompe, è possibile formattarne e promuoverne uno nuovo basandosi su un altro controller di dominio o tramite IFM, riducendo notevolmente la complessità del ripristino.

Inoltre, vale la pena ricordare limitazioni come quella Le copie dello stato del sistema sono valide solo durante il periodo di validità del teschio. (60, 90, 180 giorni a seconda della configurazione) per evitare di ripristinare oggetti eliminati e che le chiavi macchina NTLM cambino ogni 7 giorni. Nei ripristini molto vecchi potrebbe essere necessario reimposta gli account del team problemi derivanti da "Utenti e computer di Active Directory" o anche la loro rimozione e successiva riaggiunta al dominio.

Avere in atto procedure per il backup regolare dello stato del sistema, Documentare in modo chiaro i ruoli FSMO, il catalogo globale e la topologia di replica.Testare le procedure di ripristino in un ambiente di laboratorio è un investimento di tempo che evita molti grattacapi quando un controller di dominio si corrompe o qualcuno applica uno snapshot senza pensarci.

Articolo correlato:

Funzionalità di sicurezza avanzate e nuove caratteristiche chiave in Windows Server

Isaac

Scrittore appassionato del mondo dei byte e della tecnologia in generale. Adoro condividere le mie conoscenze attraverso la scrittura, ed è quello che farò in questo blog, mostrarti tutte le cose più interessanti su gadget, software, hardware, tendenze tecnologiche e altro ancora. Il mio obiettivo è aiutarti a navigare nel mondo digitale in modo semplice e divertente.