• Articolo

Amministrazione Windows -

Ripristino di emergenza: utenti e gruppi di Active Directory

Gil Kirkpatrick

 

Panoramica:

  • Funzionamento della replica e del collegamento di oggetti
  • Utilizzo di NTDSUTIL per i processi di backup e ripristino
  • Ripristino autorevole e ripristino non autorevole

Active Directory rappresenta uno dei servizi più importanti in una rete di Windows. Per evitare tempi di inattività e perdita di produttività, è essenziale sviluppare piani di ripristino di emergenza efficaci in caso di problemi correlati ad Active Directory. Sebbene questa considerazione possa sembrare ovvia, è tuttavia

sorprendente scoprire quanti amministratori non dispongano di un piano di ripristino per uno dei più comuni scenari di errore di Active Directory®, ovvero l'eliminazione accidentale dei dati.

L'eliminazione accidentale di oggetti è una delle cause principali più comuni degli errori di servizi. Nel corso di seminari e conferenze mi rivolgo spesso alla platea per chiedere se qualcuno si sia mai trovato nella necessità di gestire un errore di Active Directory dovuto all'eliminazione accidentale di dati. E ogni volta accade che quasi tutti alzino la mano.

Per comprendere la ragione della complessità del processo di ripristino dei dati, è necessario innanzitutto acquisire familiarità con le tematiche seguenti: modalità di archiviazione, replica ed eliminazione di oggetti in Active Directory e funzionamento dei processi di ripristino autorevole e non autorevole.

Archiviazione di oggetti

Active Directory è un database di oggetti specializzato che consente di implementare il modello di dati X.500/LDAP. L'archivio dati, denominato Directory Information Tree o DIT, è basato su ESE (Extensible Storage Engine), un motore di database basato su ISAM (Indexed Sequential Access Method). Dal punto di vista concettuale, Active Directory archivia il DIT in due tabelle: la tabella dei dati (che contiene gli oggetti e gli attributi effettivi di Active Directory) e la tabella dei collegamenti (che contiene le relazioni tra gli oggetti).

Ogni oggetto di Active Directory viene archiviato in una riga separata della tabella dei dati, con una colonna per ogni attributo. La tabella dei dati contiene tutte le voci relative a tutte le repliche archiviate nel controller di dominio. In un normale controller di dominio, la tabella dei dati contiene voci del contesto dei nomi (NC, Naming Context) dei domini, del contesto dei nomi della configurazione e del contesto dei nomi degli schemi. In un catalogo globale, la tabella dei dati contiene le voci relative a ciascun oggetto della foresta.

Active Directory prevede l'utilizzo del DNT (Distinguished Name Tag), un valore integer a 32 bit, per identificare in modo univoco ciascuna riga all'interno della tabella dei dati. Il DNT, utilizzato per fare riferimento agli oggetti internamente, è molto più piccolo di altri identificatori, come il nome distinto (DN, Distinguished Name) e l'objectGUID (una struttura binaria a 16 bit). Tuttavia, a differenza dell'objectGUID, il DNT è un identificatore locale ed è diverso in ciascun controller di dominio.

Collegamento di oggetti in Active Directory

Active Directory gestisce due tipi di relazioni tra gli oggetti nel DIT: la relazione padre-figlio (definita anche relazione di contenitore) e la relazione di tipo Riferimento (definita anche relazione di collegamento). Per implementare la relazione padre-figlio, Active Directory archivia una colonna aggiuntiva nella tabella dei dati denominata PDNT (Parent Distinguished Name Tag). Questa colonna contiene sempre il DNT del padre dell'oggetto.

Ogni attributo in Active Directory viene definito da un oggetto attributeSchema nel contenitore degli schemi di Active Directory. Alcuni attributi in Active Directory vengono definiti come attributi di collegamento, come determinato da un valore pari diverso da zero nell'attributo linkID dell'oggetto attributeSchema. Gli attributi di collegamento stabiliscono una relazione tra gli oggetti nella directory e possono essere a valore singolo o multivalore. L'attributo member di un oggetto gruppo è un esempio di attributo di collegamento multivalore, in quanto stabilisce un collegamento tra l'oggetto gruppo e i relativi oggetti membro.

Sebbene sembri che l'attributo member di un gruppo contenga i nomi distinti dei membri (come visualizzato ad esempio nello snap-in Utenti e computer di Active Directory) in Active Directory gli oggetti non vengono archiviati in questo modo. Quando si aggiunge il nome distinto di un oggetto membro a un attributo member di un gruppo, in Active Directory viene archiviato il DNT, non il nome distinto, dell'oggetto. Poiché il DNT non viene modificato, anche quando un oggetto viene rinominato, se si rinomina un oggetto utente, Active Directory non dovrà riorganizzare tutti i gruppi all'interno del sistema per aggiornare il nome distinto in ciascuno degli attributi member. Questo consente quindi ad Active Directory di mantenere l'integrità referenziale all'interno del DIT. Nella Figura 1 viene illustrata una rappresentazione, notevolmente semplificata, delle relazioni tra la tabella dei dati e la tabella dei collegamenti. In queste tabelle viene indicato che i tre oggetti utente, Molly Clark, Alexander Tumanov e Makoto Yamagishi, sono tutti membri del gruppo Senior Engineers.

Figure 1 Relazione tra le tabelle dei dati e le tabelle dei collegamenti

Tabella dei dati      
DNT PDNT Classe dell'oggetto Cn
14529 14401 organizationalUnit Engineers
14530 14529 Gruppo Senior Engineers
14531 14529 Utente Molly Clark
14532 14529 Utente Alexander Tumanov
14533 14529 Utente Makoto Yamagishi
Tabella dei collegamenti      
Attributo DNT Collegamento in avanti  
Member 14530 14531  
Member 14530 14532  
Member 14530 14533  

Questi collegamenti sono definiti collegamenti in avanti. Analogamente, Active Directory fornisce anche attributi di collegamento a ritroso. Questi attributi forniscono un riferimento dall'oggetto collegato all'oggetto che vi fa riferimento, ovvero l'oggetto con il collegamento in avanti. L'attributo memberOf per utenti e gruppi è un esempio di attributo di collegamento a ritroso. L'oggetto attributeSchema che descrive un attributo di collegamento a ritroso dispone di un valore linkID maggiore di uno rispetto al valore linkID pari dell'attributo di collegamento in avanti corrispondente. L'attributo member nello schema di Windows Server® 2003 R2 dispone ad esempio di un valore linkID pari a 2; l'attributo memberOf che funge da collegamento a ritroso dispone di un valore linkID pari a 3. Per ulteriori informazioni, nella Figura 2 viene fornito un elenco degli attributi collegati definiti per impostazione predefinita nello schema di Windows Server 2003 R2.

Figure 2 Attributi di collegamento nello schema di Windows Server 2003 R2

Attributo di collegamento in avanti linkID Attributo di collegamento a ritroso Linked
member 2 memberOf 3
manager 42 directReports 43
owner 44 ownerBL 45
siteObject 46 siteObjectBL 47
nonSecurityMember 50 nonSecurityMemberBL 51
queryPolicyObject 68 queryPolicyBL 69
privilegeHolder 70 isPrivilegeHolder 71
managedBy 72 managedObjects 73
hasPartialReplicaNCs 74    
hasMasterNCs 76 masteredBy 77
syncMembership 78    
serverReference 94 serverReferenceBL 95
bridgeheadTransportList 98 bridgeheadServerListBL 99
netbootServer 100 netbootSCPBL 101
frsComputerReference 102 frsComputerReferenceBL 103
fRSMemberReference 104 fRSMemberReferenceBL 105
fRSPrimaryMember 106    
siteLinkList 142    
siteList 144    
msCOM-PartitionLink 1040 msCOMPartitionSetLink 1041
msDSNCReplicaLocations 1044    
msFRSHubMember 1046    
msCOMUserPartitionSetLink 1048 msCOMUserLink 1049
msDSSDReferenceDomain 2000    
msDSHasInstantiatedNCs 2002    
msDSNonMembers 2014 msDSNonMembersBL 2015
msDSMembersForAzRole 2016 msDSMembersForAzRoleBL 2017
msDSOperationsForAzTask 2018 msDSOperationsForAzTaskBL 2019
msDSTasksForAzTask 2020 msDSTasksForAzTaskBL 2021
msDSOperationsForAzRole 2022 msDSOperationsForAzRoleBL 2023
msDSTasksForAzRole 2024 msDSTasksForAzRoleBL 2025
msDSHasDomainNCs 2026    
msSFU30PosixMember 2030 msSFU30PosixMemberOf 2031
msDShasMasterNCs 2036 msDsmasteredBy 2037
msDSObjectReference 2038 msDSObjectReferenceBL 2039
msDFSRComputerReference 2050 msDFSRComputerReferenceBL 2051
msDFSRMemberReference 2052 msDFSRMemberReferenceBL 2053

Gli attributi di collegamento a ritroso sono sempre multivalore e vengono gestiti automaticamente da Active Directory. Non è possibile infatti modificare direttamente un attributo di collegamento a ritroso. Sebbene sembri che sia possibile modificare l'attributo memberOf di un utente o gruppo tramite lo snap-in MMC Utenti e computer di Active Directory, in realtà lo snap-in consente di modificare solo l'attributo member del gruppo corrispondente e l'attributo memberOf viene automaticamente aggiornato da Active Directory in background. Per questo motivo, non è necessario disporre di autorizzazioni sull'oggetto utente per aggiungere l'utente a un gruppo, in quanto, in realtà, viene modificato solo l'attributo member dell'oggetto gruppo. Poiché ogni controller di dominio gestisce i relativi attributi di collegamento a ritroso in modalità locale, le modifiche ai collegamenti a ritroso non vengono mai replicate. Viene replicata solo la modifica all'attributo di collegamento in avanti, come l'attributo member di un gruppo.

In un normale controller di dominio, la tabella dei dati contiene voci relative agli oggetti dei domini e agli oggetti dei contenitori della configurazione e degli schemi. Alcuni tipi di gruppi possono tuttavia contenere riferimenti a oggetti che risiedono in un altro dominio. In che modo Active Directory archivia un DNT per un oggetto non contenuto nella relativa tabella dei dati? La risposta sta nel ruolo del proprietario FSMO (Flexible Single Master Operations) del master infrastrutture e nei cosiddetti oggetti non visibili (phantom).

Oggetti non visibili (phantom)

Quando si aggiunge un membro di un dominio a un gruppo di un altro dominio, Active Directory crea automaticamente nella tabella dei dati un oggetto speciale definito oggetto non visibile (phantom), che contiene l'objectGUID, l'objectSid e il nome distinto del nuovo membro. Questo oggetto fornisce un DNT che può essere archiviato nell'attributo member del gruppo. Se un controller di dominio è un catalogo globale, non è necessario che crei un oggetto non visibile (phantom) in quanto nella relativa tabella dei dati è già presente una voce per ciascun oggetto della foresta.

Il controller di dominio che contiene il ruolo FSMO del master infrastrutture controlla periodicamente le voci nella relativa tabella dei dati in base a un catalogo globale e, quando rileva che un oggetto è stato spostato, rinominato o aggiornato, aggiorna gli oggetti non visibili (phantom) nella tabella dei dati e replica le modifiche apportate negli altri controller di dominio all'interno del dominio. Grazie al conteggio dei riferimenti, il master infrastrutture è inoltre in grado di rimuovere gli oggetti non visibili (phantom) a cui nessun attributo di collegamento in avanti all'interno del dominio fa più riferimento.

Gli oggetti non visibili (phantom) consentono ai controller di dominio di gestire riferimenti a oggetti in altri domini all'interno della foresta, ma gli attributi di collegamento in avanti possono anche fare riferimento a oggetti all'esterno della foresta, ad esempio oggetti di un dominio trusted. In questo caso, Active Directory crea un oggetto denominato entità di protezione esterna (FSP, Foreign Security Principal) nel contenitore CN=ForeignSecurityPrincipals del contesto dei nomi del dominio. FSP contiene l'ID di protezione (SID, Security Identifier) dell'oggetto esterno e altri attributi che identificano l'oggetto nel dominio esterno, ma non esiste alcun processo in grado di garantire che l'oggetto FSP venga mantenuto aggiornato. Ai fini del ripristino dei dati, gli oggetti FSP verranno considerati alla stessa stregua di qualsiasi altro oggetto di Active Directory.

Eliminazione di oggetti

In questa sezione l'attenzione verrà focalizzata principalmente sul ripristino degli utenti e delle relative appartenenze ai gruppi. Gli stessi principi sono tuttavia applicabili al ripristino di altri attributi collegati.

Quando Active Directory elimina un oggetto, quest'ultimo non viene eliminato fisicamente dal DIT. L'oggetto viene invece contrassegnato come eliminato mediante l'impostazione del relativo attributo isDeleted su true, il che rende l'oggetto invisibile alle normali operazioni di directory. Active Directory rimuove tutti gli attributi non progettati per essere salvati, come definito dallo schema, e modifica il nome distinto relativo (RDN, Relative Distinguished Name) dell'oggetto in <RDN precedente>\0aDEL:<objectGUID>. Sposta quindi l'oggetto nel contenitore CN=Deleted Objects per il contesto dei nomi. Nel contesto dei nomi della configurazione sono presenti alcune classi di oggetti che Active Directory non sposta nel contenitore degli oggetti eliminati. Active Directory rimuove tutti i collegamenti in avanti agli altri oggetti contenuti nell'oggetto eliminato, con conseguente riduzione del relativo conteggio dei riferimenti nella tabella dei collegamenti. Se sono presenti altri oggetti che contengono collegamenti in avanti all'oggetto eliminato, Active Directory rimuoverà anche tali collegamenti.

L'oggetto risultante viene definito oggetto contrassegnato per rimozione. Active Directory replica l'oggetto contrassegnato per rimozione in altri controller di dominio, in cui vengono apportate le stesse modifiche. Tenere presente che Active Directory non replica le modifiche apportate ai collegamenti in avanti che fanno riferimento all'oggetto eliminato. Ogni controller di dominio apporta la modifica equivalente in modalità locale e pertanto non è necessario replicarla. Questo comportamento ha conseguenze sul ripristino delle appartenenze ai gruppi, come verrà illustrato più avanti in questo articolo.

Active Directory mantiene gli oggetti contrassegnati per rimozione nel DIT, come determinato dall'attributo tombstoneLifetime dell'oggetto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain>. Il processo di garbage collection in ciascun controller di dominio rimuove gli oggetti contrassegnati per rimozione antecedenti rispetto alla durata oggetto contrassegnato per rimozione configurata. Per impostazione predefinita, la durata oggetto contrassegnato per rimozione è di 60 giorni per Windows® 2000, Windows Server 2003 e Windows Server 2003 R2. È invece di 180 giorni per Windows Server 2003 SP1.

La durata oggetto contrassegnato per rimozione ha un impatto significativo sul processo di ripristino. Non è possibile eseguire il ripristino di un backup anteriore alla durata oggetto contrassegnato per rimozione. Poiché agli oggetti che sono stati eliminati e successivamente sottoposti al processo di garbage collection nel dominio non sono più associati oggetti contrassegnati per rimozione, l'operazione di eliminazione non verrà mai replicata nuovamente nel controller di dominio ripristinato. Gli oggetti eliminati rimarranno nel controller di dominio ripristinato come oggetti residui e il controller di dominio ripristinato non eseguirà mai la convergenza con gli altri controller di dominio all'interno del dominio.

Replica di oggetti

Quando un controller di dominio esegue un'operazione di aggiornamento di qualsiasi tipo, ad esempio l'aggiunta di un oggetto o la modifica di un attributo, il controller di dominio assegna un numero univoco a 64 bit all'operazione di aggiornamento, definito numero di sequenza di aggiornamento (USN, Update Sequence Number). Active Directory contrassegna gli oggetti e gli attributi aggiornati con il numero di sequenza di aggiornamento per determinare se è necessario replicarli.

Gli oggetti in Active Directory vengono replicati in base ai singoli attributi. Se, ad esempio, si modifica un attributo di un oggetto, Active Directory replicherà solo tale attributo, non l'intero oggetto. Per eseguire questa operazione, Active Directory tiene traccia delle modifiche apportate a ciascun attributo con i metadati della replica. I metadati della replica per un attributo includono:

  • Il numero di sequenza di aggiornamento locale, che identifica l'operazione di modifica nel controller di dominio locale.
  • L'attributo invocationID del controller di dominio da cui ha origine la modifica (più specificamente l'attributo invocationID dell'oggetto nTDSSettings corrispondente del controller di dominio), che identifica una specifica generazione del DIT in un controller di dominio.
  • Il numero di sequenza di aggiornamento dell'operazione originale esistente nel controller di dominio di origine.
  • Un timestamp che contiene l'ora di sistema del controller di dominio in cui è stata apportata la modifica di origine.
  • Un numero di versione sequenziale a 32 bit che viene incrementato ogni volta che il valore viene modificato.

Quando un controller di dominio di destinazione richiede modifiche al partner del dominio di origine corrispondente, invia il numero di sequenza di aggiornamento dell'ultima modifica replicata al controller di origine insieme a un vettore di aggiornamento che include il numero di sequenza di aggiornamento di origine più elevato che il controller di dominio di destinazione ha rilevato in ciascun controller di dominio in cui è in corso la replica di una replica del contesto dei nomi. Il controller di dominio di origine utilizza queste informazioni per inviare solo gli aggiornamenti che il controller di dominio di destinazione non ha ancora rilevato.

Mentre elabora gli aggiornamenti degli attributi in ingresso, il controller di dominio di destinazione controlla il numero di versione di ciascun attributo. Se il numero di versione di un attributo in ingresso è maggiore della versione già esistente nel controller di dominio per tale attributo, verrà memorizzato il valore in ingresso. Se il numero di versione in ingresso è uguale alla versione già esistente nel controller di dominio, quest'ultimo confronta i timestamp e utilizza l'attributo con il timestamp più recente. Se i timestamp sono identici, il controller di dominio di destinazione sceglie il valore con l'attributo invocationID più elevato. Questo garantisce che ogni controller di dominio scelga lo stesso valore per ogni attributo replicato.

Replica del valore collegato

In Windows 2000, la replica degli attributi multivalore in Active Directory veniva eseguita allo stesso modo della replica degli attributi a valore singolo. Questo causava problemi per gli oggetti gruppo dinamici di grandi dimensioni il cui attributo member multivalore poteva essere modificato di frequente in controller di dominio differenti. Se un amministratore aggiungeva un utente a un gruppo in un controller di dominio e un altro amministratore aggiungeva un utente differente al gruppo in un altro controller di dominio all'interno dell'intervallo di latenza di replica, Active Directory sceglieva l'aggiunta più recente che sostituiva completamente quella precedente. Microsoft ha ovviato a questo problema in Windows Server 2003 con un processo definito replica del valore collegato (LVR, Linked Value Replication).

Utilizzando il livello di funzionalità della foresta di Windows Server 2003 o Windows Server 2003 interim, Active Directory replica i singoli valori degli attributi di collegamento in avanti multivalore separatamente, in cui ciascun valore dispone di propri metadati di replica. Questo consente di risolvere in modo efficace il problema riscontrato in Windows 2000 dove aggiornamenti quasi simultanei dell'appartenenza ai gruppi in controller di dominio differenti poteva causare una perdita di dati.

È necessario tuttavia prendere in considerazione un importante fattore. L'aumento del livello di funzionalità della foresta non determina la correzione automatica degli attributi di collegamento multivalore esistenti con i nuovi metadati della replica. Solo i valori che vengono aggiunti dopo l'aumento del livello di funzionalità della foresta includeranno i nuovi metadati. Questo avrà un effetto significativo sul ripristino delle appartenenze ai gruppi, come verrà illustrato più avanti.

Backup

Windows include l'utilità di base NTBACKUP, che può essere utilizzata per eseguire il backup dello stato di sistema di un controller di dominio. Lo stato di sistema di un controller di dominio include il relativo Registro di sistema, SYSVOL, i file DIT di Active Directory e i file di sistema critici. Anche la maggior parte delle utilità di backup di terze parti è in grado di eseguire il backup e il ripristino dello stato di sistema di un controller di dominio.

Per eseguire il backup dello stato di sistema di un file su disco, utilizzare il comando seguente:

NTBACKUP backup systemstate /F “<filename>”

In questo comando <nomefile> rappresenta il nome del file di backup da creare e deve utilizzare l'estensione .bkf.

Esecuzione di un ripristino non autorevole

Il ripristino degli oggetti di Active Directory eliminati dal backup è un processo a due fasi. È necessario innanzitutto riavviare il controller di dominio in modalità ripristino servizi directory (DSRM, Directory Services Restore mode) e successivamente ripristinare l'intero database DIT di Active Directory dal backup dello stato di sistema utilizzando l'utilità NTBACKUP di Windows o un prodotto di terze parti equivalente. Questo processo sovrascriverà l'intero DIT.

Esistono due metodi per avviare un controller di dominio in modalità ripristino servizi directory. Se si accede alla console di sistema del controller di dominio, arrestare e riavviare il controller di dominio, quindi premere F8 quando viene chiesto di aprire il menu di avvio di Windows. Selezionare Modalità ripristino servizi directory dal menu e immettere la password per la modalità ripristino servizi directory.

Se si gestisce il server in modalità remota, non si sarà in grado di accedere al menu di avvio di Windows. È possibile modificare le opzioni di avvio di sistema selezionando Proprietà da Risorse del computer, facendo clic sulla scheda Avanzate e selezionando il pulsante Impostazioni in Avvio e ripristino. Scegliere il pulsante Modifica nella sezione Avvio del sistema per modificare il file boot.ini, quindi aggiungere l'opzione /SAFE­BOOT:DSREPAIR alla fine della riga, come illustrato nella Figura 3. Per ulteriori informazioni sulle opzioni per boot.ini, visitare il sito Web all'indirizzo microsoft.com/technet/ sysinternals/information/bootini.mspx.

Figura 3 Impostazione delle opzioni di avvio per la modalità ripristino servizi directory

Figura 3** Impostazione delle opzioni di avvio per la modalità ripristino servizi directory **(Fare clic sull'immagine per ingrandirla)

Quando si riavvia il server, viene attivata la modalità ripristino servizi directory. Ricordare che è necessario rimuovere l'opzione /SAFEBOOT dal file boot.ini quando si desidera riavviare il controller di dominio in modalità normale.

Una volta eseguito l'accesso con la password per la modalità ripristino servizi directory, ripristinare il backup dello stato di sistema utilizzando di nuovo il comando NTBACKUP ma senza specificare alcun parametro. Non è possibile eseguire un ripristino utilizzando NTBACKUP dalla riga di comando. Quando viene visualizzata la procedura guidata, selezionare Ripristino dei file e delle impostazioni, quindi scegliere Avanti. Selezionare quindi il file di backup e la casella Stato del sistema, come illustrato nella Figura 4.

Figura 4 Utilizzo di Backup o ripristino guidato per ripristinare lo stato del sistema

Figura 4** Utilizzo di Backup o ripristino guidato per ripristinare lo stato del sistema **(Fare clic sull'immagine per ingrandirla)

Se, a questo punto, si decidesse di avviare il controller di dominio di nuovo in modalità normale, il processo di replica di Active Directory ripristinerebbe la sincronizzazione tra il controller di dominio ripristinato e gli altri controller di dominio all'interno del dominio e tutti i dati ripristinati verrebbero sovrascritti dai dati correnti. Ovviamente, questo non è l'obiettivo che si intende raggiungere. È necessario invece un metodo che consenta di forzare la replica degli oggetti ripristinati negli altri controller di dominio all'interno del dominio.

Esecuzione di un ripristino autorevole

NTDSUTIL consente di aumentare il numero di versione di ciascun attributo di 100.000 volte per ciascun giorno trascorso tra la data del backup e la data del ripristino. A meno che non vi siano attributi che vengano aggiornati più di 100.000 volte al giorno (uno scenario piuttosto inverosimile), il numero di versione degli attributi ripristinati sarà di gran lunga maggiore rispetto ai numeri di versione contenuti in altri controller di dominio e l'oggetto ripristinato autorevolmente verrà replicato negli altri controller di dominio. Gli altri oggetti ripristinati in modo non autorevole dal backup verranno sovrascritti dai dati esistenti negli altri controller di dominio.

Dopo aver completato il ripristino non autorevole ma prima di eseguire il riavvio in modalità normale, utilizzare il programma NTDSUTIL per eseguire un ripristino autorevole degli oggetti che si desidera ripristinare. Il ripristino autorevole di un oggetto non consente di ripristinare effettivamente l'oggetto, ma assicura semplicemente che Active Directory replichi l'oggetto negli altri controller di dominio. A tal fine, NTDSUTIL assegna il successivo numero di sequenza di aggiornamento disponibile al numero di sequenza di aggiornamento locale degli attributi dell'oggetto. Questo determina l'invio dell'oggetto ai partner di replica la volta successiva che vengono sincronizzati. Per ripristinare un singolo oggetto, verificare che il controller di dominio venga avviato in modalità ripristino servizio directory, quindi attenersi alla procedura seguente:

  1. Aprire una finestra di comando e digitare:
ntdsutil
  1. Al prompt di ntdsutil digitare:
authoritative restore
  1. Al prompt di ripristino autorevole digitare:
restore object “<DN of object to be restored>”
  1. Se, ad esempio, si desidera ripristinare l'account Molly Clark dall'unità organizzativa Eng nel dominio DRNET, immettere:
restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
  1. Se si desidera eseguire un ripristino autorevole di un'intera sottostruttura di directory, ad esempio un'unità organizzativa, immettere:
restore subtree “OU=Eng,DC=DRNET,DC=com”
  1. NTDSUTIL fornisce inoltre un comando di ripristino del database che consente di eseguire il ripristino autorevole dell'intero dominio e dei contesti dei nomi della configurazione e degli schemi. Il ripristino dell'intero dominio espone a notevoli pericoli e pertanto è consigliabile non utilizzare questa opzione. Se si desidera ripristinare un intero domino, è consigliabile ripristinare un controller di dominio e innalzare nuovamente di livello gli altri controller di dominio all'interno del dominio, come descritto in "Pianificazione del ripristino della foresta di Active Directory".
  2. Quando richiesto, confermare che il ripristino autorevole deve aumentare i numeri di versione dei rispettivi oggetti e dei relativi attributi.
  3. Uscire da ntdsutil (è necessario digitare quit due volte).
  4. Riavviare il controller di dominio nella modalità normale di Active Directory.

La volta successiva che il controller di dominio esegue la replica con i relativi partner, l'utente ripristinato verrà replicato. Tuttavia, il ripristino dell'oggetto utente rappresenta solo una parte del problema. Quando si inseriscono collegamenti di oggetti come quelli tra un gruppo e i relativi membri, la situazione diventa più complessa. Durante e dopo il processo di ripristino è possibile che ci si trovi a dover affrontare due problemi fondamentali, che verranno descritti nelle sezioni successive.

Ma prima occorre esaminare le possibile conseguenze dell'eliminazione di un oggetto con collegamenti a ritroso. Si supponga di eliminare un oggetto utente membro di uno o più gruppi. Ogni controller di dominio che dispone di una copia dell'oggetto utente lo convertirà in un oggetto contrassegnato per rimozione e rimuoverà eventuali riferimenti dalla tabella dei collegamenti, determinando pertanto la rimozione dell'oggetto utente da qualsiasi appartenenza ai gruppi nel dominio dell'utente. Tenere presente che la rimozione dell'utente dall'appartenenza ai gruppi non è una modifica replicata in quanto ogni controller di dominio aggiorna l'appartenenza al gruppo in modalità locale. Il numero di versione il numero di sequenza di aggiornamento locale dell'attributo member del gruppo restano invariati. Dopo un breve periodo di tempo, gli oggetti non visibili (phantom) verranno rimossi dalle tabelle dei collegamenti in altri domini senza aggiornare i metadati della replica dell'attributo member del gruppo.

Quando si esegue un ripristino non autorevole del DIT in un controller di dominio all'interno del dominio dell'utente, l'oggetto utente viene ripristinato insieme a tutte le appartenenze ai gruppi all'interno del dominio, il che garantisce pertanto la coerenza interna del controller di dominio ripristinato. Dopo aver utilizzato l'utilità NTDSUTIL per eseguire il ripristino autorevole dell'utente, l'oggetto utente viene replicato in tutti gli altri controller di dominio all'interno del dominio.

Tuttavia, poiché i metadati della replica dei gruppi correnti nel dominio restano invariati, gli attributi member dei gruppi nel controller di dominio ripristinato non sono coerenti con quelli degli altri controller di dominio. Non essendo inoltre disponibile alcun metodo per eseguire la convergenza tra i controller di dominio in uno stato comune, le appartenenze dell'utente non verranno ripristinate negli altri controller di dominio all'interno del dominio.

Problema: impossibile ripristinare le appartenenze ai gruppi all'interno del dominio

Il ripristino autorevole dell'oggetto utente non consente di ripristinare i gruppi a cui l'utente appartiene. Perché? Perché la relazione di appartenenza viene archiviata e replicata mediante l'attributo member degli oggetti gruppo (collegamenti in avanti), non l'attributo memberOf dell'utente (collegamento a ritroso). Il problema sta nell'individuare le appartenenze ai gruppi precedenti dell'utente e nell'identificare il metodo appropriato per ripristinarle.

Microsoft ha apportato miglioramenti incrementali al processo di ripristino delle appartenenze ai gruppi di un utente. Pertanto, la tecnica utilizzata dipende dalla versione di Active Directory in esecuzione. La sezione riportata di seguito è applicabile principalmente ad Active Directory di Windows 2000.

La determinazione delle appartenenze ai gruppi precedenti di un utente è piuttosto semplice: occorre semplicemente esaminare l'attributo di collegamento a ritroso nel controller di dominio ripristinato, in questo caso l'attributo memberOf dell'oggetto utente. L'attributo memberOf contiene tutte le appartenenze ai gruppi locali e globali all'interno del dominio dell'utente. Per elencare le appartenenze ai gruppi dell'utente ripristinato, è possibile utilizzare lo snap-in MMC Utenti e computer di Active Directory (ADUC) o l'utilità LDIFDE, inclusa in Windows Server.

Nella riga di comando di LDIFDE seguente vengono elencati i gruppi del dominio DRNET di cui Molly Clark è membro, archiviando i risultati nel file output.ldf:

C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf

Tenere presente che è necessario avviare il controller di dominio in modalità normale per utilizzare gli strumenti LDAP e occorre disattivare la replica in ingresso; in caso contrario i dati ripristinati verranno sovrascritti. Il metodo più semplice per disattivare la replica in ingresso consiste nell'utilizzo del comando REPADMIN:

REPADMIN /options <dcname>+DISABLE_INBOUND_REPL

In questo comando <nomedc> rappresenta il nome del controller di dominio in cui si sta eseguendo il ripristino. Al termine, ricordare inoltre di riattivare la replica utilizzando DISABLE_INBOUND_REPL.

Il ripristino di un numero limitato di utenti può essere eseguito con un'attività piuttosto semplice: è sufficiente aggiungere di nuovo l'utente ai gruppi manualmente mediante ADUC. Se si intende ripristinare un numero elevato di utenti, sono disponibili alcuni strumenti in grado di automatizzare parte del processo. L'utilità Microsoft GROUPADD (disponibile nel Servizio Supporto Tecnico Clienti Microsoft) può accettare il file LDIF creato per elencare le appartenenze ai gruppi precedenti dell'utente e, a sua volta, genera un file LDIF che crea nuovamente tali appartenenze. Il comando GROUPADD può essere utilizzato ad esempio per elaborare il file LDIF creato nell'esempio precedente per Molly Clark:

C:\> groupadd /after_restore output.ldf

Questo comando consente di creare un nuovo file LDIF per ciascun dominio che contiene le appartenenze ai gruppi precedenti di Molly Clark con il nome groupadd_<dominio>.ldf (dove <dominio> rappresenta il nome di dominio completo del dominio di cui verranno aggiornati i gruppi). Il file LDIF creato in precedenza può essere importato con il comando seguente:

C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf

Con Windows Server 2003, Microsoft ha migliorato l'utilità NTDSUTIL in modo da utilizzare i metadati aggiuntivi presenti nell'attributo member per supportare la replica del valore collegato. Se l'oggetto utente ripristinato fosse stato membro di un gruppo qualsiasi all'interno del dominio e l'appartenenza al gruppo dell'utente fosse stata archiviata con i metadati della replica del valore collegato, l'utilità NTDSUTIL avrebbe aumentato il numero di versione del valore corrispondente dell'attributo member, determinando la replica dell'appartenenza ripristinata.

La versione Windows Server 2003 SP1 di NTDSUTIL incorpora le funzioni GROUPADD e prevede la creazione automatica dei file LDIF durante il ripristino autorevole dell'oggetto utente. Nella Figura 5 viene illustrata la nuova versione di NTDSUTIL, mentre nella Figura 6 viene mostrato il contenuto del file LDIF creato automaticamente.

Figure 6 Contenuto del file LDIF creato tramite NTDSUTIL

dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-

Figura 5 Nuova utilità NTDSUTIL con funzionalità GROUPADD incorporate

Figura 5** Nuova utilità NTDSUTIL con funzionalità GROUPADD incorporate **(Fare clic sull'immagine per ingrandirla)

Se si sta ripristinando un'intera unità organizzativa che contiene numerosi utenti e gruppi, aggiungere di nuovo gli utenti ai relativi gruppi manualmente è un'attività piuttosto noiosa. Un altro metodo per ripristinare le appartenenze ai gruppi ripristinate prevede l'esecuzione del ripristino autorevole dei gruppi stessi.

Il ripristino autorevole dei gruppi comporta tuttavia due problemi principali. Il primo è abbastanza ovvio: se si ripristina un gruppo, l'appartenenza a tale gruppo verrà riportata allo stato in cui si trovava quando è stato effettuato il backup. Ne consegue che tutte le modifiche apportate al gruppo dall'ultimo backup dovranno essere riapplicate al gruppo. Il secondo problema non risulta immediatamente evidente e riguarda il funzionamento del processo di replica di Active Directory. Dopo un ripristino autorevole di utenti e gruppi non è possibile sapere in alcun modo in quale ordine questi verranno replicati. Se un oggetto gruppo viene replicato in controller di dominio prima dell'oggetto utente ripristinato, il controller di dominio di replica rimuoverà automaticamente il riferimento all'utente dal gruppo in quanto l'oggetto utente non esiste ancora in tale controller di dominio. Quando l'oggetto utente viene replicato in seguito, non viene aggiunto al gruppo.

La soluzione più semplice a questo problema consiste nell'eseguire il ripristino autorevole dei gruppi una seconda volta. Dopo aver eseguito il primo ripristino autorevole, eseguire il riavvio in modalità normale e accertarsi che la replica venga eseguita in modo corretto. Eseguire quindi il riavvio in modalità ripristino servizio directory ed eseguire l'utilità NTDSUTIL per effettuare un ripristino autorevole dei gruppi di cui l'utente era membro. Questo garantisce che, quando si esegue il riavvio di nuovo in modalità normale, l'oggetto utente venga replicato prima che venga eseguita la replica degli oggetti gruppo che vi fanno riferimento.

Problema: impossibile ripristinare le appartenenze ai gruppi in altri domini

L'identificazione dei gruppi di cui l'utente era membro è un processo molto più complesso di quanto sia stato descritto in questa sede. L'utente che si sta ripristinando potrebbe essere stato membro dei gruppi universali e locali di dominio in altri domini e le appartenenze a tali gruppi non vengono ripristinate quando si esegue un ripristino non autorevole. Come è possibile pertanto identificare i gruppi a cui l'utente apparteneva in altri domini? La risposta risiede nel catalogo globale. Oltre ai dati del rispettivo dominio, il catalogo globale contiene una copia di sola lettura dei dati degli altri domini della foresta.

Per utilizzare i dati a livello dell'intera foresta di un catalogo globale è necessario eseguire il ripristino non autorevole sul catalogo globale. A tal fine, occorre innanzitutto eseguire il backup del catalogo globale. Quando si esegue l'utilità LDIFDE per identificare le appartenenze ai gruppi dell'utente, è possibile individuare le appartenenze ai gruppi universali dell'utente in altri domini.

Quando si elencano le appartenenze ai gruppi dell'utente che si sta ripristinando, connettersi alla porta del catalogo globale 3268 anziché alla porta predefinita 389 e specificare il dominio radice della foresta come base della ricerca. LDIFDE visualizzerà le appartenenze ai gruppi dell'utente ripristinato, inclusa l'appartenenza ai gruppi universali in tutti i domini della foresta. Di seguito viene illustrato come eseguire questa operazione:

C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf

Se si esegue GROUPADD o la nuova utilità NTDSUTIL in un catalogo globale, verrà creato un file LDIF per il dominio dell'utente e un file LDIF per ciascun dominio in cui l'utente ripristinato è stato membro di un gruppo universale. Durante l'importazione di questi file vengono ripristinate tutte le appartenenze ai gruppi dell'utente. Questo porta a esaminare il problema successivo.

Problema: ripristino delle appartenenze ai gruppi locali di dominio in altri domini

Esistono tre tipi di gruppi in un ambiente Active Directory di Windows. I gruppi globali possono contenere solo i membri all'interno dello stesso domini ma possono essere utilizzati come membri di gruppi locali di dominio sia nel rispettivo dominio che negli altri domini della foresta. L'attributo member dei gruppi globali non viene visualizzato nel catalogo globale, ma questo non rappresenta un problema in quanto i gruppi globali contengono solo i membri del rispettivo dominio. I gruppi universali possono contenere i membri di qualsiasi dominio e possono essere utilizzati come membri di altri gruppi universali all'interno della foresta e come membri dei gruppi locali di dominio sia all'interno del rispettivo dominio che in altri domini della foresta. L'attributo member dei gruppi universali viene replicato nei cataloghi globali. I gruppi locali di dominio possono contenere i membri di qualsiasi dominio della foresta ma non possono essere utilizzati come membri di gruppi di altri domini. Cosa ancora più importante, l'attributo member dei gruppi locali di dominio, come quello dei gruppi globali, non viene visualizzato nel catalogo globale. Ne consegue che non esiste un metodo semplice per ripristinare appartenenza dell'utente ai gruppi locali di dominio in altri domini.

Prima di Windows Server 2003 SP1, l'unico metodo per ripristinare le appartenenze ai gruppi locali di dominio in domini esterni prevedeva il ripristino di un controller di dominio in ciascun dominio, la ricerca manuale dei dati del dominio per tutti i gruppi locali di dominio che contenevano l'utente ripristinato e infine l'aggiunta dell'utente ai gruppi identificati. In un ambiente di grandi dimensioni con numerosi domini l'implementazione di questo approccio richiede molto tempo.

Da questo punto di vista, la versione Windows Server 2003 SP1 di NTDSUTIL può risultare particolarmente utile. Quando si esegue l'utilità NTDSUTIL in un controller di dominio, l'utilità crea un file di testo che contiene il nome distinto e il GUID degli oggetti utente ripristinati. Per ogni dominio esterno è possibile eseguire il ripristino non autorevole di un singolo controller di dominio, copiare il file di testo nel controller di dominio ed eseguire l'utilità NTDSUTIL per generare un nuovo file LDIF specifico del dominio che consente di aggiungere l'utente ripristinato di nuovo ai gruppi locali di dominio di cui era membro.

A tal fine, in un controller di dominio in ciascun dominio esterno effettuare le operazioni seguenti:

  1. Avviare il controller di dominio nel dominio esterno in modalità ripristino servizi directory.
  2. Utilizzare NTBACKUP per ripristinare una copia del DIT che contiene le appartenenze ai gruppi dell'utente ripristinato.
  3. Copiare il file .txt creato da NTDSUTIL nel controller di dominio corrente.
  4. Aprire una finestra di comando e digitare ntdsutil.
  5. Digitare authoritative restore.
  6. Digitare create LDIF file(s) from <nome file> (dove <nome file> rappresenta il nome del file di testo).
  7. Digitare quit due volte per uscire da ntdsutil.
  8. Riavviare il controller di dominio nella modalità normale di Active Directory.
  9. Digitare ldifde –i –f <nomefile ldif> (dove <nomefile ldif> rappresenta il nome del file LDIF appena creato).

A questo punto, sono state ripristinate tutte le appartenenze ai gruppi dell'utente eliminato.

Procedura dettagliata

Il ripristino degli utenti di Active Directory e delle relative appartenenze ai gruppi, in particolare in un ambiente con più domini, è un processo molto complesso. I passaggi specifici necessari per ripristinare in modo corretto le appartenenze ai gruppi variano in base alla versione di Windows in esecuzione.

Se si esegue Windows 2003 SP1, attenersi alla procedura seguente:

  1. Avviare un processo di garbage collection in modalità ripristino servizi directory ed eseguire u ripristino dello stato di sistema utilizzando un backup che contiene l'utente eliminato.
  2. Utilizzare l'utilità NTDSUTIL per eseguire un ripristino autorevole dell'utente eliminato. NTDSUTIL creerà un file di testo contenente i nomi distinti e i GUID degli oggetti ripristinati e uno o più file LDIF per ripristinare le appartenenze ai gruppi dell'utente.
  3. Utilizzare LDIFDE –i –f <nomefile LDIF> (dove <nomefile LDIF> rappresenta il nome dei file LDIF creati nel passaggio 2) per importare le appartenenze ai gruppi nel dominio corrente e in altri domini.
  4. Riavviare il catalogo globale in modalità normale.
  5. In un controller di dominio all'interno di ciascun dominio esterno eseguire l'avvio in modalità ripristino servizi directory ed eseguire un ripristino dello stato di sistema utilizzando un backup che contiene le appartenenze ai gruppi dell'utente ripristinato.
  6. Eseguire NTDSUTIL utilizzando il comando per la creazione dei file ldif.
  7. Riavviare il controller di dominio in modalità normale.
  8. Utilizzare LDIFDE –i –f <nomefile> (dove <nomefile> rappresenta il nome del file LDIF creato nel passaggio 6) per ripristinare le appartenenze ai gruppi nel dominio esterno.
  9. A questo punto è possibile, se si desidera, forzare la replica con REPADMIN /syncall.

Se si esegue una versione di Windows Server 2003 senza SP1 installato o si esegue Windows 2000, è necessario eseguire alcuni passaggi aggiuntivi. Poiché la versione precedente di NTDSUTIL non prevede la creazione dei file LDIF, utilizzare l'utilità GROUPADD per crearli. Il processo viene illustrato di seguito:

  1. Avviare un catalogo globale in modalità ripristino servizi directory ed eseguire un ripristino dello stato di sistema utilizzando un backup che contiene l'utente eliminato.
  2. Disattivare la scheda NIC o scollegare il cavo per impedire la replica in ingresso.
  3. Riavviare il catalogo globale in modalità normale.
  4. Utilizzare LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf per eseguire il dump dell'appartenenza dell'utente con il nome distinto <dn>.
  5. Utilizzare GROUPADD /after_restore membership.ldf per creare i file LDIF.
  6. Utilizzare LDIFDE –i –f <nomefile> (dove <nomefile LDIF> rappresenta il nome del file LDIF creato da GROUPADD nel passaggio 5) per importare le appartenenze ai gruppi nel dominio corrente e in altri domini.
  7. Riattivare la replica in ingresso utilizzando REPADMIN /options <nomedc> -DISABLE_INBOUND_REPL.
  8. In un controller di dominio in ciascun dominio esterno, eseguire l'avvio in modalità ripristino servizi directory ed eseguire un ripristino dello stato di sistema utilizzando un backup che contiene le appartenenze ai gruppi dell'utente ripristinato.
  9. Riavviare il controller di dominio in modalità normale.
  10. Utilizzare LDIFDE –i –f <nomefile> (dove <nomefile> rappresenta il nome del file LDIF creato da GROUPADD nel passaggio 5) per ripristinare le appartenenze ai gruppi nel dominio esterno.
  11. A questo punto, se si desidera, è possibile forzare la replica REPADMIN /syncall.

L'unica operazione da eseguire a questo punto in un ambiente precedente a Windows Server 2003 SP1 consiste nel ripristinare le appartenenze ai gruppi locali dei domini esterni dell'utente ripristinato. Sono disponibili solo due opzioni: ripristinare manualmente le appartenenze ai gruppi locali di dominio o ripristinare il backup di un controller di dominio ed eseguire un ripristino autorevole dei gruppi locali di dominio.

Riepilogo

Sebbene sia piuttosto semplice eliminare accidentalmente utenti o persino unità organizzative da Active Directory, il ripristino degli utenti eliminati e delle relative appartenenze ai gruppi può essere un processo molto complesso, lungo e tendente all'errore. Per poter essere in grado di eseguire un ripristino di emergenza in modo rapido ed efficace in situazioni di questo tipo, è necessario comprendere il funzionamento dei processi di collegamento di oggetti, replica, eliminazione e ripristino autorevole.

Sarebbe tuttavia assurdo pensare di ottenere risultati ottimali la prima volta che si implementa un piano di ripristino di emergenza nell'ambiente di produzione. Per assicurarsi di disporre della preparazione adeguata per gestire in modo efficace situazioni che richiedono il ripristino di oggetti eliminati, è consigliabile predisporre un piano scritto. Assicurarsi inoltre di è sicuro di testare il piano almeno una o due volte prima di implementarlo su dati reali. Questo comportamento sarà senza dubbio apprezzato dal proprio capo e dal CEO.

Ulteriori risorse

Gil Kirkpatrick è CTO di NetPro e si occupa dello sviluppo di software per Active Directory dal 1996. In collaborazione con Guido Grillenmeier di HP, ha realizzato i noti workshop sul ripristino di emergenza in Active Directory. Gil è anche il fondatore della Directory Experts Conference (www.dec2007.com).

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.