Share via


Ripristino foresta Active Directory - Determinare come ripristinare la foresta

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 e 2012

Il ripristino di un'intera foresta Active Directory comporta il ripristino di almeno un controller di dominio in ogni dominio da un backup disponibile. Il ripristino della foresta ripristina ogni dominio nella foresta al relativo stato al momento dell'ultimo backup attendibile.

Dati che andranno persi

L'operazione di ripristino comporterà la perdita di almeno i dati di Active Directory seguenti:

  • Tutti gli oggetti (ad esempio utenti e computer) aggiunti dopo l'ultimo backup attendibile
  • Tutti gli aggiornamenti apportati agli oggetti esistenti dall'ultimo backup attendibile
  • Tutte le modifiche apportate alla partizione di configurazione o alla partizione dello schema in Active Directory Domain Services (ad esempio le modifiche dello schema) dall'ultimo backup attendibile

Conoscenza delle password

  1. È necessario conoscere la password di un account amministratore di dominio per ogni dominio nella foresta. Preferibilmente, si tratta della password dell'account Administrator predefinito.
  2. È anche necessario conoscere la password DSRM per eseguire un ripristino dello stato del sistema di un controller di dominio.

È consigliabile archiviare l'account Administrator e la cronologia delle password DSRM in un luogo sicuro, per il periodo di validità dei backup. Ovvero, entro il periodo di durata della rimozione definitiva o entro il periodo di durata dell'oggetto eliminato se il Cestino di Active Directory è abilitato.

È anche possibile sincronizzare la password DSRM con un account utente di dominio affinché sia più facile da ricordare. Per altre informazioni, vedi questo articolo. La sincronizzazione dell'account DSRM deve essere eseguita prima del ripristino della foresta, come parte della preparazione.

Nota

Per impostazione predefinita, l'account Administrator è membro del gruppo Administrators predefinito, così come i gruppi Domain Admins ed Enterprise Admins. Questo gruppo ha il controllo completo di tutti i controller di dominio nel dominio.

Determinare il backup da usare

Eseguire regolarmente il backup di almeno due controller di dominio scrivibili per ogni dominio, in modo da avere più backup tra cui scegliere. Selezionare uno o più controller di dominio in base alle esigenze e il master operazioni dell'emulatore PDC per il ripristino dei dati SYSVOL.

Nota

Non è possibile usare il backup di un controller di dominio di sola lettura per ripristinare un controller di dominio scrivibile. È consigliabile ripristinare i controller di dominio usando i backup eseguiti alcuni giorni prima dell'occorrenza dell'errore. In generale, è necessario stabilire un compromesso tra l'attualità e la sicurezza dei dati ripristinati. Se si sceglie un backup più recente si recuperano dati più utili, ma potrebbe aumentare il rischio di reintroduzione di dati pericolosi nella foresta ripristinata.

Il ripristino dei backup dello stato del sistema dipende dal server e dal sistema operativo originali del backup. Ad esempio, non è consigliabile ripristinare un backup dello stato del sistema in un server diverso. In questo caso, potrebbe essere visualizzato l'avviso seguente:

Avviso

Il backup specificato è di un server diverso da quello corrente. Non è consigliabile eseguire un ripristino dello stato del sistema con il backup in un server alternativo perché il server potrebbe diventare inutilizzabile. Usare questo backup per il ripristino del server corrente?

Se è necessario ripristinare Active Directory in un componente hardware diverso, creare backup completi del server e pianificare l'esecuzione di un ripristino completo del server.

Importante

Il ripristino del backup dello stato del sistema in una nuova installazione di Windows Server in un nuovo hardware o nello stesso hardware non è supportato. Se Windows Server viene reinstallato nello stesso hardware (scelta consigliata), è possibile ripristinare il controller di dominio in questo ordine:

  1. Eseguire un ripristino completo del server per ripristinare il sistema operativo e tutti i file e le applicazioni.
  2. Eseguire un ripristino dello stato del sistema usando wbadmin.exe per contrassegnare SYSVOL come autorevole.

Per altre informazioni, vedere Come ripristinare un'installazione di Windows 7.

Se l'ora dell'errore non è nota, indagare ulteriormente per identificare i backup che contengono l'ultimo stato sicuro della foresta.

Questo approccio è meno preferibile. Di conseguenza, è consigliabile mantenere log dettagliati sullo stato di integrità di Active Directory Domain Services su base giornaliera, in modo che, in caso di errore a livello di foresta, sia possibile identificare l'ora approssimativa dell'errore. È anche consigliabile mantenere una copia locale dei backup per consentire un ripristino più rapido.

Se il Cestino di Active Directory è abilitato, la durata del backup è uguale al valore di deletedObjectLifetime o al valore di tombstoneLifetime, a seconda del valore inferiore. Per altre informazioni, vedere Guida dettagliata sul Cestino per Active Directory.

In alternativa, è possibile usare lo strumento di montaggio del database di Active Directory Dsamain.exe e uno strumento LDAP (Lightweight Directory Access Protocol), ad esempio Ldp.exe o Utenti e computer di Active Directory, per identificare quale backup include l'ultimo stato sicuro della foresta. Lo strumento di montaggio del database di Active Directory, incluso nei sistemi operativi Windows Server, espone i dati di Active Directory archiviati in backup o snapshot come server LDAP. È possibile usare uno strumento LDAP per esplorare i dati. Questo approccio ha il vantaggio di non richiedere il riavvio di un controller di dominio in modalità ripristino servizi directory (DSRM) per esaminare il contenuto del backup di Active Directory Domain Services.

Per altre informazioni sull'utilizzo dello strumento di montaggio del database di Active Directory, vedere Guida dettagliata allo strumento di montaggio del database di Active Directory.

È anche possibile usare il comando ntdsutil snapshot per creare snapshot del database di Active Directory. Pianificando un'attività per creare periodicamente gli snapshot, è possibile ottenere copie aggiuntive del database di Active Directory nel tempo. È possibile usare queste copie per identificare meglio quando si è verificato l'errore a livello di foresta e quindi scegliere il backup migliore da ripristinare. Per creare gli snapshot, usare ntdsutil o strumenti di amministrazione remota del server.

Il controller di dominio di destinazione può eseguire qualsiasi versione di Windows Server. Per altre informazioni sull'utilizzo del comando ntdsutil snapshot, vedere Snapshot.

Determinare i controller di dominio da ripristinare

La facilità del processo di ripristino è un fattore importante quando si decide quale controller di dominio ripristinare. È consigliabile disporre di un controller di dominio dedicato per ogni dominio che è il controller di dominio preferito per un ripristino. Un controller di dominio di ripristino dedicato semplifica la pianificazione e l'esecuzione affidabili del ripristino della foresta perché si usa la stessa configurazione di origine usata per eseguire i test di ripristino. È possibile creare script per il ripristino ed evitare la contesa con configurazioni diverse, ad esempio se il controller di dominio contiene ruoli master operazioni o se si tratta di un server di catalogo globale o DNS.

Nota

Non è consigliabile ripristinare un titolare del ruolo master operazioni nell'interesse della semplicità, perché vengono sempre acquisiti tutti i ruoli. Esiste il caso di un ripristino SYSVOL usando un backup eseguito dal master operazioni dell'emulatore PDC, in quanto generalmente il PDC dispone della migliore copia dei dati SYSVOL.

Un backup valido è un backup che può essere ripristinato correttamente, che è stato eseguito alcuni giorni prima dell'errore e che contiene il maggior numero possibile di dati utili. Scegliere un controller di dominio che soddisfi al meglio i criteri seguenti:

  • Un controller di dominio scrivibile. Questo criterio è obbligatorio.

  • Un controller di dominio che esegue Windows Server 2012 o versione successiva come macchina virtuale in un hypervisor che supporta VM-GenerationID. Questo controller di dominio può essere usato come origine per la clonazione. In generale, usare un controller di dominio con un backup valido contenente il sistema operativo più recente.

  • Un controller di dominio accessibile, fisicamente o in una rete virtuale, e preferibilmente situato in un data center. In questo modo, è possibile isolarlo facilmente dalla rete durante il ripristino della foresta.

  • Un controller di dominio con un backup completo del server valido.

  • Un controller di dominio che esegue il ruolo DNS (Domain Name System) e ospita la foresta e la zona dei domini.

  • Un controller di dominio configurato come catalogo globale.

  • Un controller di dominio che non è configurato per l'utilizzo dello sblocco di rete via BitLocker, se si usano i Servizi di distribuzione Windows. L'utilizzo dello sblocco di rete via BitLocker per il primo controller di dominio ripristinato dal backup durante un ripristino della foresta non è supportato. Nei controller di dominio in cui sono stati distribuiti i Servizi di distribuzione Windows (WDS), non è possibile usare lo sblocco di rete via BitLocker come unica protezione con chiave perché il primo controller di dominio richiederebbe che Active Directory e WDS fossero funzionanti per procedere allo sblocco. Prima di ripristinare il primo controller di dominio, Active Directory non è ancora disponibile per Servizi di distribuzione di Windows, quindi non è possibile procedere allo sblocco.

    Per determinare se un controller di dominio è configurato per l'utilizzo dello sblocco di rete via BitLocker, verificare che un certificato di sblocco di rete sia identificato nella chiave del Registro di sistema seguente:

    HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemCertificatesFVE_NKP

Importante

Osservare le procedure di sicurezza durante la gestione o il ripristino dei file di backup che includono Active Directory. L'urgenza che accompagna il ripristino della foresta può causare involontariamente la mancata osservanza delle procedure consigliate per la sicurezza.

Identificare la struttura della foresta corrente e le funzioni del controller di dominio

Determinare la struttura della foresta corrente identificando tutti i domini nella foresta. Creare un elenco di tutti i controller di dominio in ogni dominio, in particolare i controller di dominio con backup e i controller di dominio virtualizzati che possono essere un'origine per la clonazione.

L'elenco dei controller di dominio per il dominio radice della foresta è il più importante perché questo dominio verrà ripristinato per primo. Dopo aver ripristinato il dominio radice della foresta, è possibile ottenere un elenco degli altri domini, controller di dominio e siti nella foresta usando gli snap-in di Active Directory.

Per ogni dominio nella foresta, identificare un singolo controller di dominio scrivibile con un backup attendibile del database di Active Directory per tale dominio. Prestare attenzione quando si sceglie un backup per ripristinare un controller di dominio. Se il giorno e la causa dell'errore sono noti, è consigliabile identificare e usare un backup sicuro eseguito alcuni giorni prima di tale data.

Preparare una tabella che mostra le funzioni di ogni controller di dominio nel dominio, come illustrato nell'esempio seguente. In questo modo sarà possibile ripristinare la configurazione della foresta esistente prima dell'errore dopo il ripristino.

Nome del controller di dominio Sistema operativo FSMO GC Controller di dominio di sola lettura Backup DNS Server Core VM
DC_1 Windows Server 2019 Master schema, master per la denominazione dei domini No No No
DC_2 Windows Server 2019 Nessuno No No
DC_3 Windows Server 2022 Master infrastrutture No No No
DC_4 Windows Server 2022 Emulatore PDC, master RID No No No No
DC_5 Windows Server 2022 Nessuno No No No
Controller di dominio di sola lettura_1 Windows Server 2016 Nessuno
Controller di dominio di sola lettura_2 Windows Server 2022 Nessuno No

In questo esempio precedente sono disponibili quattro candidati per il backup: DC_1, DC_2, DC_4 e DC_5. Di questi candidati per il backup, ne verrà ripristinato solo uno. Il controller di dominio consigliato è DC_5 per i seguenti motivi:

  • Si tratta di un'origine valida per la clonazione di controller di dominio virtualizzati, perché esegue Windows Server 2022 come controller di dominio virtuale ed esegue software che può essere clonato (o che si può rimuovere se non può essere clonato). Dopo il ripristino, il ruolo emulatore PDC verrà acquisito in tale server e può essere aggiunto al gruppo Controller di dominio clonabili per il dominio.
  • Esegue un'installazione completa di Windows Server 2022. Un controller di dominio che esegue un'installazione di base del server può essere una destinazione meno adatta per il ripristino. Questo potrebbe non essere un fattore importante se si è in grado di gestire i server Windows tramite l'interfaccia della riga di comando.
  • È un server DNS.

Nota

Poiché DC_5 non è un server di catalogo globale, presenta un lieve vantaggio in quanto il catalogo globale non deve essere rimosso dopo il ripristino. Tuttavia, è necessario avviare il ripristino con l'account Administrator predefinito con RID 500 o usare il valore del Registro di sistema ignoregcfailures:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Value: IgnoreGCFailures
Type: REG_DWORD
Data: 0 – Require GlobalCatalog for logon (default)
1 – Allow logon without groups from GC

Altri fattori sono in genere più importanti del passaggio aggiuntivo di rimozione del ruolo catalogo globale. Anche DC_3 o DC_4 sono scelte valide perché i ruoli master operazione non costituiscono un problema. Valutare le opzioni e scegliere in base alla situazione di ripristino effettiva. In genere si procede con la pianificazione e il test ripristinando il backup del master operazioni PDC, ma se il backup non funziona, ad esempio perché l'ora non è corretta, selezionare un backup da un catalogo globale dello stesso dominio.

Ripristinare la foresta in isolamento

Lo scenario preferito consiste nell'arrestare tutti i controller di dominio scrivibili prima che il primo controller di dominio ripristinato venga spostato nell'ambiente di produzione. In questo modo, tutti i dati pericolosi non vengono replicati nuovamente nella foresta ripristinata. È particolarmente importante arrestare tutti i titolari del ruolo master operazioni.

Nota

In alcuni casi è possibile spostare il primo controller di dominio che si prevede di ripristinare per ogni dominio in una rete isolata, consentendo ad altri controller di dominio di rimanere online per ridurre al minimo i tempi di inattività del sistema. Se, ad esempio, si esegue il ripristino da un aggiornamento dello schema non riuscito, è possibile scegliere di mantenere i controller di dominio in esecuzione nella rete di produzione durante l'esecuzione della procedura di ripristino in isolamento.

Controller di dominio virtualizzati

Se si eseguono controller di dominio virtualizzati, è possibile spostarli in una rete virtuale isolata dalla rete di produzione in cui verrà eseguito il ripristino. Lo spostamento dei controller di dominio virtualizzati in una rete separata offre due vantaggi:

  • I controller di dominio ripristinati non possono riprodurre il problema che ha causato il ripristino della foresta.
  • La clonazione dei controller di dominio virtualizzati può essere eseguita sulla rete isolata affinché sia possibile eseguire e testare un numero critico di controller di dominio prima di essere spostati nuovamente nella rete di produzione.

Controller di dominio fisici

Se si eseguono controller di dominio su hardware fisico, disconnettere il cavo di rete del primo controller di dominio che si prevede di ripristinare nel dominio radice della foresta. Se possibile, disconnettere anche i cavi di rete di tutti gli altri controller di dominio. Questo approccio impedisce la replica dei controller di dominio, qualora vengano avviati accidentalmente durante il processo di ripristino della foresta.

Foreste di grandi dimensioni

In una foresta di grandi dimensioni che si estende su più località, può essere difficile garantire che tutti i controller di dominio scrivibili vengano arrestati. Per questo motivo, i passaggi di ripristino, ad esempio la reimpostazione dell'account del computer e dell'account krbtgt, oltre alla pulizia dei metadati, sono progettati per garantire che i controller di dominio scrivibili ripristinati non vengano replicati con controller di dominio scrivibili pericolosi (qualora alcuni di essi siano ancora online nella foresta).

Tuttavia, solo portando offline i controller di dominio scrivibili è possibile garantire che la replica non si verifichi. Di conseguenza, quando possibile, è necessario distribuire una tecnologia di gestione remota che consenta di arrestare e isolare fisicamente i controller di dominio scrivibili durante il ripristino della foresta.

Controller di dominio di sola lettura

I controller di dominio di sola lettura possono continuare a funzionare mentre i controller di dominio scrivibili sono offline. Nessun altro controller di dominio replicherà direttamente le modifiche dai controller di dominio di sola lettura, in particolare nessuna modifica dello schema o del contenitore di configurazione, quindi non pongono gli stessi rischi dei controller di dominio scrivibili durante il ripristino. Dopo che tutti i controller di dominio scrivibili sono stati ripristinati e riportati online, è necessario ricreare tutti i controller di dominio di sola lettura.

I controller di dominio di sola lettura continueranno a consentire l'accesso alle risorse locali memorizzate nella cache nei rispettivi siti mentre in parallelo sono in corso le operazioni di ripristino. Per le risorse locali che non sono memorizzate nella cache nel controller di dominio di sola lettura, le richieste di autenticazione verranno inoltrate a un controller di dominio scrivibile. Queste richieste avranno esito negativo perché i controller di dominio scrivibili sono offline. Alcune operazioni come le modifiche delle password, non funzioneranno fino a quando i controller di dominio scrivibili non vengono ripristinati.

Se si usa un'architettura di rete hub e spoke, è possibile concentrarsi innanzitutto sul ripristino dei controller di dominio scrivibili nei siti hub. Successivamente, è possibile ricreare i controller di dominio di sola lettura nei siti remoti.

Database di Active Directory compromesso

Se il database di Active Directory di un controller di dominio scrivibile viene compromesso, è necessario creare una nuova chiave radice del Servizio distribuzione chiavi (KDS) dopo il ripristino e ricreare tutti gli account del servizio gestiti del gruppo (gMSA) a seconda dello scenario di compromissione. I dettagli sono descritti qui: Come eseguire il ripristino da un attacco Golden gMSA.

Passaggi successivi