Raffaele Valensise

Procedure di Ripristino di Domain Controller – Parte IV

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

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).

Scenario 2: Perdita di un Domain Controller con il ruolo di Global Catalog

La perdita di un Domain Controller con il ruolo di Global Catalog (GC) può avere un impatto significativo sull’infrastruttura Active Directory:

  • Accesso e autenticazione utenti: Il Global Catalog contiene informazioni parziali di tutti gli oggetti in tutta la Forest Active Directory, permettendo agli utenti di effettuare il login e di accedere alle risorse in modo efficiente. Se il DC che funge da GC non è più disponibile e non ci sono altri GC raggiungibili, gli utenti potrebbero non riuscire a eseguire il login o ad accedere alle risorse di rete, soprattutto in ambienti di grandi dimensioni.
  • Ricerche globali nella directory: Le query che richiedono informazioni su oggetti in altri domini della Forest dipendono dal Global Catalog. Senza un GC disponibile, queste ricerche falliranno.
  • Impatto sulle applicazioni: Applicazioni che si appoggiano al Global Catalog per recuperare dati sugli utenti o sugli oggetti della directory possono smettere di funzionare correttamente o presentare errori.
  • Replica e coerenza: La perdita di un DC GC può influire sulla replica e sulla sincronizzazione delle informazioni, anche se la replica in sé è gestita da tutti i DC. È importante intervenire per ripristinare la funzionalità completa del GC per mantenere la salute della Forest.

Step 1: Verifiche iniziali

  1. Anche in questo caso, come detto nel precedente articolo, è fondamentale assicurarsi che il DC sia effettivamente irrecuperabile.
  2. Confermare l’eventuale presenza di altri Global Catalog: se altri DC nella rete sono configurati come GC, l’impatto sarà meno grave, poiché gli utenti e i servizi possono indirizzarsi a questi altri server (vedi procedure descritte nel secondo articolo, https://www.ictpower.it/sistemi-operativi/procedure-di-ripristino-di-domain-controller-parte-ii.htm)

Step 2: Aggiungere il ruolo Global Catalog a un altro DC

Avviare la console Active Directory Sites and Services.

Espandere la cartella Sites, poi il sito contenente il DC da verificare, poi la cartella Servers.

Espandere l’oggetto server relativo al DC che si intende configurare come GC.

Fare clic con il pulsante destro su NTDS Settings e selezionare Properties.

Nella scheda General, selezionare la casella Global Catalog.

Step 3: Verificare la replica Active Directory

Avviare una sessione Command Prompt con privilegi amministrativi.

Eseguire il comando:

repadmin /replsummary

Avviare una sessione PowerShell con privilegi amministrativi.

Eseguire il comando:

Get-ADDomainController -Filter {IsGlobalCatalog -eq $true} | ForEach-Object {Get-ADReplicationPartnerMetadata -Target $_.Name | Select-Object Server, Partner, LastReplicationSuccess}


Step 4: Pulizia dei metadati

Se il DC perso non può essere recuperato, come già discusso, è necessario rimuovere i suoi metadati da Active Directory per evitare problemi di replica e autenticazione.

Rimandiamo alle procedure di Metadata Cleanup descritte nel precedente articolo.

Scenario 3: Perdita di un Domain Controller con uno o più ruoli FSMO

La perdita di un DC che detiene uno o più ruoli FSMO richiede un intervento tempestivo per garantire la continuità operativa di Active Directory.

Normalmente, i ruoli FSMO sono assegnati o trasferiti mediante procedure specifiche che garantiscono che solo un DC alla volta detenga ciascun ruolo, evitando conflitti e garantendo la coerenza dei dati nella Forest o nel Dominio.

Il trasferimento è la modalità preferita per spostare un ruolo FSMO da un DC a un altro quando entrambi sono operativi e comunicanti: il ruolo viene trasferito in modo ordinato, con il “consenso” del detentore attuale, evitando interruzioni di servizio.

La procedura di trasferimento può essere effettuata tramite console MMC o da riga di comando con il tool ntdsutil.exe.

Nel caso in cui, invece, il DC che detiene il ruolo non sia più disponibile occorre procedere con una procedura di “seizing” (sequestro), ossia una modalità di assegnazione forzata del ruolo ad un altro DC. Questa operazione deve essere eseguita con cautela, perché dopo il seizing, il vecchio Domain Controller deve essere considerato definitivamente fuori servizio e rimosso dalla Forest.

Nota: Il seizing è necessario anche nel caso in cui sia stato utilizzato uno dei seguenti comandi per forzare la retrocessione di un DC che detiene un ruolo FSMO:

  • Uninstall-ADDSDomainController -ForceRemoval
  • dcpromo /forceremoval

Step 1: Verifiche iniziali

  1. Assicurarsi che il DC sia effettivamente irrecuperabile.
  2. Accedere ad un DC disponibile e verificare la distribuzione dei ruoli FSMO nella Forest tramite una sessione di Command Prompt con privilegi amministrativi:

netdom query fsmo


Step 2: Seizing dei Ruoli FSMO

ATTENZIONE! Le operazioni descritte nel seguito sono critiche!

Accedere ad un DC disponibile (si raccomanda che sia lo stesso DC che dovrà assumere il ruolo FSMO) ed avviare una sessione di Command Prompt con privilegi amministrativi:

  • Membro del gruppo Enterprise Administrators per trasferire i ruoli di Schema Master o Domain Naming
  • Membro del gruppo Domain Administrators del dominio per trasferire i ruoli di PDC Emulator, RID Master e Infrastructure Master.

Digitare ntdsutil e premere Invio.

Digitare roles e premere Invio.

Digitare connections e premere Invio.

Digitare connect to server
<NomeDCFunzionante> (dove <NomeDCFunzionante> è il nome del DC che assumerà il ruolo che andremo a specificare) e premere Invio.

Digitare quit e premere Invio per tornare al menu fsmo maintenance.


PDC Emulator:

Digitare seize pdc e premere Invio.

Nella finestra di dialogo Role Seizure Confirmation Dialog fare clic su Yes.


Il tool tenterà dapprima di effettuare un trasferimento “sicuro” del ruolo, poi – non ricevendo risposta dal DC offline – procederà con il seizing a favore del DC indicato nei passaggi precedenti.


Infrastructure Master:

Nota: In Forest multidominio, si raccomanda che l’Infrastructure Master non sia anche un server Global Catalog. Se un DC è sia GC che Infrastructure Master, interrompe l’aggiornamento delle informazioni relative agli oggetti appartenenti ad altri domini, in quanto già presenti, ma in modo incompleto, all’interno del database del Global Catalog. Se tutti i DC del dominio sono Global Catalog, questo problema non si verifica.

Assicurarsi di essere ancora nel menu fsmo
maintenance.

Digitare seize infrastructure master e premere Invio.

Nella finestra di dialogo Role Seizure Confirmation Dialog fare clic su Yes.



RID Master:

Assicurarsi di essere ancora nel menu fsmo
maintenance.

Digitare seize rid master e premere Invio.

Nella finestra di dialogo Role Seizure Confirmation Dialog fare clic su Yes.



Domain Naming Master:

Assicurarsi di essere ancora nel menu fsmo
maintenance.

Digitare seize naming master e premere Invio.

Nella finestra di dialogo Role Seizure Confirmation Dialog fare clic su Yes.



Schema Master:

Assicurarsi di essere ancora nel menu fsmo
maintenance.

Digitare seize schema master e premere Invio.

Nella finestra di dialogo Role Seizure Confirmation Dialog fare clic su Yes.



Step 3: Verifica della distribuzione dei Ruoli FSMO

Digitare quit e premere Invio per uscire dal menu fsmo
maintenance.

Digitare quit e premere Invio per uscire dal tool ntdsutil.exe.

Digitare netdom query fsmo e premere Invio per verificare lo stato dei ruoli FSMO.

Step 4: Pulizia dei Metadati

Dopo il sequestro dei ruoli, è essenziale rimuovere i riferimenti al DC non più disponibile: rimandiamo alle procedure di Metadata Cleanup descritte nel precedente articolo.

Cosa accade se un DC viene riportato on-line dopo averne effettuato la rimozione forzata?

Riportare online un Domain Controller dopo che è stata effettuata una rimozione forzata tramite Metadata Cleanup è una pratica errata che può portare a gravi problemi di inconsistenza e di instabilità all’interno di Active Directory.

Il Metadata Cleanup, infatti, rimuove manualmente da Active Directory tutti i riferimenti ad un DC, inclusi gli oggetti computer e NTDS Settings, nonché le connessioni di replica e i ruoli FSMO (eventualmente) detenuti dal DC rimosso. Questa operazione fa sì che gli altri DC considerino quel controller come non più esistente in Active Directory.

Se il DC “eliminato” viene riacceso e messo online senza una corretta reinstallazione o reintegrazione nel dominio, esso sarà in uno stato inconsistente rispetto agli altri DC, poiché la sua presenza non è più registrata nei metadati di Active Directory.

Gli effetti collaterali generali includono la reintroduzione di oggetti residui (lingering objects), ovvero oggetti (utenti, computer, gruppi) che erano stati eliminati e la cui rimozione era stata replicata sugli altri DC, ma che esistono ancora nel database del DC riacceso. Questi oggetti potrebbero riapparire in Active Directory, causando confusione e problemi di accesso.

Differenziando gli effetti a seconda del ruolo che il DC aveva prima della rimozione forzata (e della successiva assegnazione di tali ruoli ad altri DC):

  • Se il DC era un Global Catalog: Un GC contiene una copia parziale di tutti gli oggetti della foresta. Se un GC obsoleto viene riportato online, potrebbe fornire informazioni non aggiornate o contenere oggetti residui. Questo può portare a problemi di logon per gli utenti (specialmente in ambienti multi-dominio, dove il GC è cruciale per risolvere le appartenenze a gruppi universali), errori nelle ricerche di oggetti nella Forest e malfunzionamenti di applicazioni che si affidano al GC per ottenere informazioni sugli attributi degli oggetti.
  • Se il DC deteneva uno o più ruoli FSMO: Anche se i ruoli FSMO sono stati “sequestrati” e assegnati a un altro DC prima, durante o dopo il Metadata Cleanup, il vecchio DC, una volta online, potrebbe tentare di riaffermare la sua precedente titolarità su tali ruoli se la sua copia di Active Directory non è a conoscenza del sequestro.
    • Schema Master: Se il vecchio DC tenta di comportarsi come Schema Master, potrebbe cercare di propagare modifiche allo schema basate su una versione obsoleta, causando conflitti di schema o impedendo future modifiche.
    • Domain Naming Master: Potrebbero sorgere problemi nella creazione o rimozione di domini nella Forest, o conflitti se il vecchio DC tenta di gestire lo spazio dei nomi di dominio basandosi su informazioni obsolete.
    • RID Master: C’è il rischio significativo che il vecchio DC, credendosi ancora il RID Master, inizi a distribuire pool di RID già allocati dal nuovo RID Master, portando alla creazione di oggetti con SID duplicati, un problema estremamente grave per la sicurezza e l’integrità di Active Directory.
    • PDC Emulator: Il rientro in linea di un vecchio PDC Emulator può causare problemi con la sincronizzazione dell’orario nel Dominio (essendone la fonte autoritativa), la gestione delle modifiche delle password, la propagazione immediata dei lock degli account e l’elaborazione dei Group Policy Object (GPO). Potrebbero verificarsi anche problemi di autenticazione.
    • Infrastructure Master: Se il vecchio DC era l’Infrastructure Master e non era anche un Global Catalog, e viene riacceso, potrebbe tentare di aggiornare i riferimenti a oggetti in altri Domini (i cosiddetti phantom records) in modo errato, basandosi su dati di appartenenza a gruppi universali obsoleti, causando potenziali problemi di accesso a risorse inter-dominio.

Conclusioni

In questo articolo abbiamo descritto le procedure per riassegnare ad altri Domain Controller i ruoli critici a livello di Dominio e di Forest: Global Catalog e FSMO.

Nella prossima puntata vedremo come ripristinare correttamente un Domain Controller da backup.