Amministrazione di Windows

Guida alla replica di Active Directory

Laura E. Hunter

Panoramica:

• Transizione ad Active Directory
• Gestione della coerenza
• Gestione della risoluzione dei conflitti
• Modifiche in Windows Server 2008

Prima dell'introduzione di Windows 2000 Server e Active Directory, molti ambienti aziendali si basavano su Windows NT per l'infrastruttura server e la gestione delle identità e degli

accessi. Dopo la sua implementazione, Windows NT® 4.0 rappresentava una soluzione solida nello spazio del sistema operativo di rete (NOS), ma presentava diversi limiti che ne rendevano difficoltosa la distribuzione in un'azienda di grandi dimensioni.

Per i principianti, Windows NT utilizzava uno spazio dei nomi piatto per memorizzare le risorse di rete, il che significava che non esisteva un metodo valido per separare le risorse in sottoinsiemi più piccoli o per configurare qualsiasi tipo di amministrazione granulare. Ad esempio, non era possibile configurare un contenitore di reparto per le risorse presenti nel reparto marketing o configurare un amministratore locale che disponesse dei diritti per reimpostare le password solo per gli utenti di quel settore. In questo modo, il concetto di sicurezza di Windows NT poteva essere riassunto nella frase "tutto o niente". Se si intendeva delegare le attività amministrative a un responsabile del supporto desktop, si era costretti a concedere più autorizzazioni di quelle concesse altrimenti.

Inoltre, Windows NT memorizzava tutte le informazioni in un database Gestione account di protezione (SAM) che non era in grado di supportare più di 40 MB. Se il database SAM superava il limite massimo consigliato (ciò si verificava con circa 25.000-40.000 oggetti, a seconda della configurazione), era necessario suddividere l'ambiente in più domini separati, il che complicava sia la gestione della rete sia l'accesso alle risorse da parte degli utenti. Ogni dominio NT conteneva un solo controller di dominio primario (PDC) che conteneva l'unica copia in lettura/scrittura del database SAM. Nonostante fosse possibile distribuire uno o più controller di dominio di backup (BDC) per fornire la tolleranza di errore, tali controller erano di sola lettura e non potevano eseguire alcun aggiornamento che richiedesse un'operazione di scrittura, come la modifica della password dell'utente.

Infine, Windows NT si basava sulla risoluzione dei nomi NetBIOS, che era basata su broadcast e che spesso generava una grande quantità di traffico dato che gli utenti ricercavano risorse di rete, in particolare se tali ricerche venivano effettuate tramite un collegamento WAN lento o utilizzato di frequente.

La nascita di un nuovo modello

Nel 2000 Microsoft ha rilasciato Windows® 2000, che comprendeva una sostanziale revisione delle precedenti soluzioni del sistema operativo di rete (NOS). Il nuovo servizio NOS, Active Directory®, era molto diverso da Windows NT. Active Directory non era basato su uno spazio dei nomi piatto, ma creato sul modello X.500 standard, che ha prodotto una struttura organizzativa gerarchica. Attualmente è possibile organizzare le risorse in più unità organizzative all'interno di un singolo dominio e delegare la gestione di ciascuna unità a un livello basato sulle attività.

Un'altra innovazione importante di Windows NT era rappresentata dal nuovo modello di replica multimaster. Il singolo controller di dominio primario e i relativi PDC erano ormai obsoleti. In Active Directory, ciascun controller di dominio aveva la possibilità di scrivere nel database di Active Directory.

Tuttavia, nonostante ciò creasse maggiore flessibilità poiché supportava ambienti di grandi dimensioni e/o decentralizzati, generava anche nuove sfide per la gestione dell'integrità di Active Directory. Se John Smith e Jane Dow apportano una modifica allo stesso oggetto in uffici situati agli angoli opposti del paese, cosa accade se tali modifiche entrano in conflitto? Il modello di replica di Active Directory stabilisce il modo in cui gli aggiornamenti vengono comunicati a tutti i controller di dominio di un ambiente, nonché il modo in cui gestire i conflitti risultanti dalla capacità multimaster di apportare modifiche praticamente da qualsiasi luogo.

I meccanismi della replica di Active Directory

Ai fini di questi esempi, discuteremo solo della replica tra siti. Fondamentalmente, la replica tra siti è stata progettata per replicare rapidamente le modifiche ai controller di dominio all'interno dello stesso sito e viene eseguita utilizzando la notifica delle modifiche. Nel caso di replica tra siti DC1 informerà DC2 che dispone delle modifiche da replicare e DC2 richiamerà tali modifiche da DC1. Allo stesso modo, DC2 informerà DC1 quando dispone di alcune modifiche e DC1 richiamerà tali modifiche da DC2. Come si può notare, tutta la replica di Active Directory ha luogo nelle operazioni pull e non push.

Poiché Active Directory è in grado di garantire una scalabilità che consente di supportare centinaia di migliaia o persino di milioni di oggetti, è necessario suddividere il database di Active Directory in sezioni, definite contesti di denominazione. Ogni controller di dominio memorizza minimo tre contesti dei nomi nella copia locale del database di Active Directory.

Contesto dei nomi dello schema Questo contesto dei nomi viene replicato in tutti gli altri controller di dominio nell'insieme di strutture e contiene informazioni sullo schema di Active Directory, che a sua volta definisce diverse classi e attributi dell'oggetto in Active Directory.

Contesto dei nomi della configurazione Replicato anche in qualsiasi altro controller di dominio nell'insieme di strutture, questo contesto dei nomi contiene informazioni sulla configurazione a livello dell'insieme di strutture relative al layout fisico di Active Directory, nonché informazioni sugli identificatori di visualizzazione e sulle quote di Active Directory a livello dell'insieme di strutture.

Contesto dei nomi del dominio Questo contesto dei nomi viene replicato in tutti gli altri controller di dominio all'interno di un solo dominio di Active Directory. Si tratta del contesto dei nomi che contiene i dati di Active Directory utilizzati più di frequente: utenti, gruppi, computer correnti, nonché altri oggetti che si trovano all'interno di un determinato dominio di Active Directory.

Per ottimizzare al meglio il traffico di replica, i contesti dei nomi vengono replicati separatamente in modo che un contesto dei nomi che si modifica raramente, come il contesto dei nomi dello schema, non sottragga la larghezza di banda necessaria per il contesto dei nomi del dominio, che sembra cambiare più frequentemente.

Poiché è possibile apportate modifiche alla directory da qualsiasi controller di dominio di Active Directory, sono disponibili due operazioni di scrittura delle quali la replica di Active Directory deve tenere traccia. Un tipo è rappresentato dalle scritture di origine, ovvero quando una particolare modifica è stata apportata direttamente in un controller di dominio particolare. Ad esempio, se si effettua la connessione a DC1 e si modifica la password di un utente, tale modifica viene considerata una scrittura di origine su DC1. È necessario, inoltre, che Active Directory tenga traccia delle scritture replicate. Come è possibile immaginare, ciò significa che una particolare modifica è stata replicata da un altro controller di dominio. La modifica considerata come scrittura di origine in DC1 verrà considerata una scrittura replicata nel momento in cui tale modifica viene replicata in DC2, DC3 e in qualunque altro controller di dominio all'interno del dominio.

I controller di dominio di Active Directory gestiscono la trasmissione delle modifiche alla directory attraverso l'uso di metadati di replica. Ciò significa che, oltre a comunicare i dati reali che sono stati modificati da un controller di dominio in un altro (la carica di John Smith è stata modificata in "Direttore delle risorse umane"), Active Directory trasmette anche altre informazioni su tale modifica per consentire ai controller di dominio di gestire la replica nel modo più efficiente possibile, ad esempio il controller di dominio da cui ha avuto origine la modifica, l'ora in cui è avvenuta la modifica e altre informazioni essenziali.

Il primo elemento dei metadati della replica che verrà affrontato è il numero di sequenza di aggiornamento (USN, Update Sequence Number). Ogni controller di dominio gestisce un USN specifico per quel controller di dominio. Ogni volta che viene apportata una modifica ad Active Directory da quel controller di dominio, il numero di sequenza di aggiornamento subisce un incremento di 1. Pertanto, se un controller di dominio dispone di un USN pari a 1000 alle 11.00 e 1005 alle 11.30, è chiaro che sono state apportate 5 modifiche al database di Active Directory in quel controller di dominio. Conoscere esattamente queste modifiche non ha alcuna importanza per quanto concerne l'USN. È possibile che siano stati modificati, creati o eliminati 5 oggetti differenti o qualsiasi combinazione, l'USN del controller di dominio crescerà sempre di 5 punti. Inoltre, i numeri di sequenza di aggiornamento sono interni a un solo controller di dominio specifico e non hanno alcuna importanza se paragonati con altri controller di dominio. Un controller di dominio in un dominio potrebbe effettuare una modifica alle 11.30 che prevede l'assegnazione di un USN di 1051, mentre un secondo controller di dominio nello stesso dominio potrebbe apportare esattamente nello stesso momento una modifica che prevede l'assegnazione di un USN di 5084. Nonostante questi due controller di dominio abbiano chiaramente USN completamente differenti a causa di una modifica apportata quasi contemporaneamente, ciò non ha alcun rilievo sulla modalità con cui tali modifiche vengono replicate; il numero di sequenza di aggiornamento di un controller di dominio non ha alcun significato per altri controller di dominio se le due modifiche vengono messe a confronto.

Ma questo non è l'unico modo in cui l'USN di un controller di dominio viene incrementato. Si tenga presente che una modifica al database di Active Directory può comportare una scrittura di origine o una scrittura replicata. Il numero di sequenza dell'aggiornamento in un controller di dominio viene incrementato da entrambi i tipi di operazioni di scrittura, il che significa che viene incrementato ogni volta che avviene la replica di una modifica in un altro controller di dominio. A questo punto è chiaro che ciascun controller di dominio necessita di un metodo per tenere traccia delle modifiche già replicate, altrimenti a ogni replica potrebbe trovarsi a inviare l'intero database di Active Directory tramite cavo. Per evitare che ciò si verifichi, ogni controller di dominio di Active Directory mantiene un valore definito vettore limite massimo (HWMV) per gli altri controller di dominio con cui esegue la replica. Ogni controller di dominio assocerà questo valore all'identificatore univoco globale (GUID) del controller di dominio remoto, per evitare qualunque confusione nel caso in cui un controller di dominio remoto venga ridenominato o rimosso dalla directory.

Iniziamo con un semplice esempio, in cui due controller di dominio sono stati configurati nel dominio contoso.com, dc1.contoso.com e dc2.contoso.com. Poiché sono presenti soltanto due controller di dominio nel dominio contoso.com, DC1 e DC2 si replicano a vicenda. Si noti che si tratta di un esempio semplificato che non indica ancora l'intera storia della replica di Active Directory. Ulteriori dettagli verranno aggiunti più avanti.

Ipotizziamo inoltre che l'attuale USN del DC1 sia 3000, che l'USN del DC2 sia 4500 e che, nel momento in cui cominciamo l'esempio questi due controller di dominio siano completamente aggiornati tra loro:

Passaggio 1: DC1 e DC2 sono aggiornati con i rispettivi dati. DC1 presenta un vettore limite massimo per DC2 di 4500, mentre DC2 presenta un vettore limite massimo per DC1 di 3000, come illustrato nella Figura 1.

Figura 1** Stato attuale dei due controller di dominio **

Passaggio 2: Un amministratore crea un nuovo oggetto nel DC1 e l'USN del DC1 viene incrementato a 3001, come illustrato nella Figura 2. Si noti che il vettore HWMV del DC1 non è cambiato in DC2, perché DC1 non ha ancora informato DC2 che è in attesa di modifiche.

Figura 2** Viene aggiunto un nuovo oggetto **

Passaggio 3: DC1 informa DC2 che sono disponibili alcune modifiche. DC2 inizia la replica con DC1 per richiedere tutti gli aggiornamenti disponibili. Nella stessa richiesta, DC2 invia a DC1 il vettore limite massimo che viene memorizzato per DC1, come illustrato nella Figura 3.

Figura 3** Notifica delle modifiche **(Fare clic sull'immagine per ingrandirla)

Passaggio 4: DC1 invia a DC2 la modifica che corrisponde a USN 3001, ovvero, l'oggetto creato su DC1 nel Passaggio 2. DC2 aggiorna il proprio USN a 4501 e il relativo HWMV per DC1 a 3001, come illustrato nella Figura 4.

Figura 4** Modifiche e aggiornamenti **(Fare clic sull'immagine per ingrandirla)

Fin qui tutto bene. Ma ecco presentarsi un problema. DC2 dispone di una modifica da replicare. Se le uniche cose da portare avanti erano gli USN e i vettori limite massimo, a questo punto DC2 dovrebbe contattare DC1 per replicare la stessa modifica appena replicata da DC1 a DC2, il che creerebbe un ciclo di replica infinito e consumerebbe progressivamente sempre più larghezza di banda. Per evitare ciò, sono necessari alcuni pezzi del puzzle, il primo del quale è il vettore di aggiornamento (vettore UTD o semplicemente UTDV).

L'UTDV è un altro pezzo dei metadati di replica che viene utilizzato per il blocco della propagazione; il suo scopo è evitare che la stessa modifica sprechi larghezza di banda mediante la replica ripetuta attraverso la rete. Ogni controller di dominio conserva una tabella UTDV per qualsiasi altro controller di dominio che memorizza una copia del contesto dei nomi in questione. Per il contesto dei nomi del dominio, ogni controller di dominio in un dominio conserva un UTDV per ciascun controller di dominio nel dominio; per il contesto dei nomi della configurazione e dello schema, viene mantenuto per ogni controller di dominio nell'insieme di strutture. La tabella UTDV tiene traccia non solo dell'USN più alto che ogni controller di dominio ha ricevuto dai partner di replica, ma anche il valore USN più alto che ha ricevuto da ciascun controller di dominio che esegue la replica di un determinato contesto dei nomi. Per tenerne conto, ogni modifica replicata contiene anche le seguenti informazioni:

• Il GUID del controller di dominio che replica la modifica. Potrebbe trattarsi di una modifica che viene replicata come una scrittura di origine o come una scrittura replicata.
• L'USN del controller di dominio che replica la modifica. Ancora una volta, ciò può avvenire da una scrittura di origine o replicata.
• Il GUID del controller di dominio che ha dato origine alla modifica. Se questo GUID è uguale al GUID del controller di dominio che replica la modifica, si tratta di una scrittura di origine. Altrimenti, entra in gioco la tabella UTDV.
• L'USN del controller di dominio che ha dato origine alla modifica. Ancora una volta, se questo USN è uguale all'USN del controller di dominio che replica la modifica, si tratta di una scrittura di origine. In caso contrario, non entra in gioco la tabella UTDV.

Per illustrare meglio questo processo, renderemo più complesso l'esempio aggiungendo un terzo controller di dominio, DC3. In questo esempio, DC1, DC2 e DC3 sono tutti partner di replica reciproci; DC1 si replica con DC2 e DC3, DC2 con DC1 e DC3, infine DC3 con DC1 e DC2:

Passaggio 1: DC1, DC2 e DC3 sono aggiornati l'uno con i dati degli altri.

Passaggio 2: DC3 esegue una singola operazione di scrittura di origine reimpostando la password per l'account utente jsmith. DC3 informa DC1 e DC2 che sono disponibili alcune modifiche. DC1 e DC2 contengono la scrittura di origine di DC3 e aggiornano le tabelle HWMV e UTDV per DC3, come illustrato nella Figura 5.

Figura 5** Aggiornamento delle tabelle HWMV e UTDV **(Fare clic sull'immagine per ingrandirla)

Passaggio 3: Ecco dove entra in gioco il vettore di aggiornamento. DC2 informa DC1 che sono disponibili alcune modifiche. DC1 contatta poi DC2 che richiede tutte le modifiche nuove inviando a DC2 le seguenti informazioni:

• Il vettore limite massimo di DC1 per DC2, in questo caso 4501.
• Tabella UTDV del DC1 (illustrata nella Figura 6), che indica l'USN di origine più elevato ricevuto da tutti i controller di dominio, compreso DC3.

Figure 6 Tabella UTDV

In base al valore HWMV di 4501, DC2 verifica che non sia stata replicata la modifica in questione a DC1 (vedere la Figura 7).

Figure 7 È necessario replicare una modifica

Tuttavia, in base alla tabella UTDV che DC1 ha trasmesso prima dell'avvio della replica, DC2 determina che DC1 non necessita effettivamente di questa modifica, poiché DC1 l'ha già ricevuta da DC3. A questo punto, DC1 aggiorna semplicemente la voce HWMV affinché DC2 rifletta l'USN incrementato, come illustrato nella Figura 8. Tuttavia, per risparmiare larghezza di banda, i dati reali non vengono inviati tramite cavo.

Figura 8** Blocco della propagazione **(Fare clic sull'immagine per ingrandirla)

Passaggio 4: Questo stesso blocco della propagazione avrà luogo quando DC2 informa DC3 della presenza di modifiche disponibili e quando DC1 informa allo stesso modo DC2 e DC3. Tutti e tre i controller di dominio aggiorneranno le rispettive voci HWMV per i propri partner di replica, come illustrato nella Figura 8, ma i dati correnti non attraverseranno nuovamente il cavo poiché sono già stati trasmessi a ciascun DC nel Passaggio 2.

Risoluzione dei conflitti in un ambiente multimaster

Fino a qui i nostri esempi rientravano in un mondo perfetto, dove un solo amministratore alla volta apporta modifiche a un controller di dominio e nessuno si sovrappone alle operazioni di qualcun altro. Nel mondo reale, ciò non avviene mai. Poiché gli aggiornamenti a un oggetto di Active Directory possono essere eseguiti da qualsiasi controller di dominio nel dominio, cosa accade se i due amministratori apportano aggiornamenti in conflitto da due controller di dominio diversi? Esistono tre tipi di conflitti che possono verificarsi in un ambiente Active Directory, ciascuno dei quali utilizza un metodo diverso di risoluzione dei conflitti.

Conflitti nelle modifiche delle proprietà . Un conflitto di questo tipo si verifica nel caso in cui due amministratori aggiornano lo stesso oggetto in maniera differente: un amministratore imposta una descrizione dell'utente su "Marketing", mentre un altro amministratore su un controller di dominio diverso imposta la descrizione di quell'utente su "Vendite e marketing".

Creazione di nuovi oggetti in conflitto . Questo conflitto si verifica se due amministratori creano contemporaneamente un oggetto con lo stesso nome, ad esempio due utenti denominati jsmith.

Spostamento di un oggetto in un contenitore eliminato . Questo tipo di conflitto è molto più raro e ha luogo se un amministratore crea o sposta un oggetto in un contenitore, ad esempio un'unità organizzativa, mentre un altro amministratore su un controller di dominio diverso elimina quel contenitore.

Per risolvere i primi due tipi di conflitti, è arrivato il momento di presentare due ulteriori parti di metadati di replica che vengono utilizzati principalmente per la risoluzione dei conflitti. Il valore versionID viene assegnato a ogni singolo attributo su un oggetto, con un valore iniziale di 1 la prima volta che viene creato l'oggetto e viene incrementato di 1 ogni volta che un singolo attributo viene modificato da qualunque controller di dominio. Pertanto, se l'attributo della descrizione di un determinato utente viene aggiornato rispetto al relativo valore predefinito (vuoto o <non impostato>) in "Reparto marketing", l'attributo della descrizione avrà un valore versionID di 2. Se, successivamente, la descrizione viene modificata in "Reparto vendite e marketing", l'attributo della descrizione avrà un valore versionID di 3, e così via. Questo valore versionID è incluso in ogni voce di replica insieme ad altre parti di metadati già presentati.

È possibile utilizzare versionID anche per ridurre il traffico di replica. Ad esempio, se un amministratore su DC2 ha apportato diverse modifiche a un singolo attributo (digitando a volte erroneamente la modifica) per cui DC2 dispone di scritture di origine che corrispondono al valore versionIDs 2, 3, 4 e 5, DC2 replicherà soltanto la scrittura che corrisponde all'ultimo valore, versionID 5. Poiché le prime modifiche verrebbero comunque semplicemente sovrascritte, si ottiene un collegamento che consente di ridurre l'utilizzo inutile della larghezza di banda.

Ogni modifica ad Active Directory include anche il secondo pezzo aggiuntivo di metadati utilizzato per la risoluzione dei conflitti, un timestamp, come parte dei metadati di replica, che indica quando è stata apportata la modifica.

L'attributo timestamp viene utilizzato anche come misura proattiva dello stato di replica di Active Directory. Se un controller di dominio non ha visualizzato alcuna modifica con un timestamp relativamente recente di un controller di dominio particolare, inizierà a generare dei messaggi di errore che indicano la possibile presenza di problema con il controller di dominio in questione.

Pertanto, come vengono utilizzati questi due attributi nella risoluzione dei conflitti? Esaminiamo singolarmente ogni tipo di conflitto.

Risoluzione dei conflitti nelle modifiche delle proprietà

Si prenda in considerazione l'esempio dell'oggetto utente jsmith nel dominio contoso.com. Un amministratore nel DC1 modifica la descrizione di jsmith in "Marketing". Quasi contemporaneamente, un amministratore nel DC3 modifica la stessa descrizione dell'utente in "Vendite e marketing". A questo punto, le informazioni di DC1 e DC3 relative all'attributo di descrizione di jsmith vengono messe a confronto, come illustrato nella Figura 9.

Figure 9 Modifiche quasi simultanee

Se DC2 riceve entrambe queste modifiche contemporaneamente, dovrà necessariamente determinare quale sia quella "vincente". L'ordine degli spareggi per la risoluzione di conflitti è il seguente:

1. La modifica che ha il valore versionID più elevato sarà accettata come modifica "vincente"; quella "perdente" verrà sovrascritta. In questo caso, il valore di versionID è 2 per entrambi i record, dunque sarà necessario passare al secondo spareggio.
2. Se entrambi i record hanno lo stesso valore di versionID, la modifica con il timestamp più recente verrà considerata come vincente; l'altra verrà sovrascritta. In questo caso, il timestamp della scrittura di origine di DC3 è successivo, pertanto la descrizione di jsmith verrà impostata su "Vendite e marketing". Nel raro caso in cui sia il valore versionID che il timestamp siano identici, sarà necessario un terzo spareggio definitivo:
3. Se entrambi i record hanno lo stesso valore versionID e timestamp, qualunque scrittura proveniente dal controller di dominio con il GUID inferiore vincerà; la scrittura con il GUID superiore verrà sovrascritta. Pertanto, se il GUID del DC1 è 1234567890 e quello del DC3 è 2345678901, la scrittura di origine del DC1 avrebbe la meglio se entrambi i valori di versionID e timestamp fossero identici.

Probabilmente verrebbe da pensare, "Non avrebbe più senso far sì che timestamp sia il primo spareggio?". Ciò non è prestabilito, come si potrebbe pensare. Se timestamp fosse lo spareggio principale nella risoluzione dei conflitti di Active Directory, l'unica cosa che dovrebbe fare un amministratore malintenzionato per diffondere le proprie modifiche sarebbe impostare di nuovo l'orologio su un controller di dominio particolare in modo che vincesse in base al timestamp.

Risoluzione dei conflitti nella creazione degli oggetti

Nel caso in cui venissero creati due oggetti con lo stesso nome, Active Directory utilizzerà gli stessi tre spareggi descritti nella sezione precedente per stabilire qual è l'oggetto "vincente". A differenza della sezione precedente, tuttavia, l'oggetto "perdente" non viene sovrascritto. Al contrario, tale oggetto viene ridenominato utilizzando il CNF dei caratteri (per l'oggetto di conflitto), seguito da due punti e dal GUID dell'oggetto "perdente". Ciò consente agli amministratori di stabilire in maniera più metodica quale oggetto deve essere conservato e quale invece eliminato.

Risoluzione dei conflitti dovuti allo spostamento di un oggetto in un contenitore eliminato

Come già accennato, la risoluzione di un conflitto dovuto allo spostamento di oggetto in un contenitore eliminato è un caso abbastanza raro che si verifica soltanto in uno dei due scenari illustrati di seguito. Nel primo, un amministratore su un controller di dominio crea un oggetto all'interno di un contenitore particolare, ad esempio Unità organizzativa di formazione, nello stesso momento in cui un amministratore in un altro controller di dominio elimina proprio tale contenitore. Il secondo scenario può verificarsi quando un amministratore in un controller di dominio sposta un oggetto in un contenitore nello stesso momento in cui un amministratore in un altro controller di dominio elimina quel contenitore.

La risoluzione in questo caso è abbastanza semplice: Active Directory sposta l'oggetto rimasto "orfano" in un contenitore speciale all'interno di Active Directory progettato proprio a questo scopo, il contenitore LostAndFound che si trova al di fuori della radice di ogni dominio Active Directory. Per il dominio contoso.com, il contenitore LostAndFound dovrebbe trovarsi nel seguente percorso LDAP: LDAP://cn=LostAndFound.dc=contoso.dc=com. Se quando viene aperto lo snap-in Utenti e computer di Active Directory non viene visualizzato il contenitore LostAndFound, è sufficiente fare clic su Visualizza | Funzionalità avanzate.

Protezione dal ripristino USN

Una delle situazioni più gravi che è possibile riscontrare in un ambiente Active Directory è anche una delle più semplici da evitare, una volta individuati la causa e il modo per risolverla. Il ripristino USN è una condizione di errore che può arrestare completamente la replica sulla rete e viene causato consentendo a un controller di dominio di rimanere non in linea per troppo tempo e poi riattivarlo o ripristinando un controller di dominio utilizzando un metodo non supportato.

Una causa implicita del ripristino USN ha a che fare con il modo in cui viene eseguita l'eliminazione degli oggetti nell'ambiente multimaster di Active Directory. Quando un oggetto viene eliminato definitivamente da un controller di dominio, l'oggetto viene contrassegnato per la rimozione definitiva in modo che tale oggetto possa essere replicato in altri controller di dominio, informandoli dell'eliminazione. In particolare, un oggetto contrassegnato per la rimozione definitiva dispone di un attributo isDeleted impostato su TRUE. Per ridurre la dimensione dell'oggetto contrassegnato per la rimozione definitiva, la maggior parte dei valori contenuti nell'oggetto, come la descrizione, le informazioni personali e l'appartenenza al gruppo di un oggetto utente, vengono rimossi (per ulteriori informazioni su questo processo, vedere l'articolo di Gil Kirkpatrick "Recupero degli oggetti contrassegnati per la rimozione definitiva di Active Directory" disponibile in linea all'indirizzo technetmagazine.com/issues/2007/09).

È possibile che si verifichi il ripristino USN perché questi oggetti non rimangono sospesi all'infinito. Per impostazione predefinita, vengono eliminati completamente dal database di Active Directory dopo 60 o 180 giorni (a seconda della versione di Windows Server® in esecuzione sul proprio computer la prima volta che è stato creato l'ambiente Active Directory). Questo periodo di 60 o di 180 giorni viene definito durata dell'oggetto contrassegnato per la rimozione definitiva. Tutti i controller di dominio devono essere in grado di replicare almeno una volta durante questo periodo altrimenti diventano inutili e creano un'opportunità per il ripristino USN. Fondamentalmente, il ripristino USN si verifica quando un controller di dominio è talmente obsoleto da non contenere più oggetti contrassegnati per la rimozione definitiva e che, pertanto, non è in grado di mantenere aggiornata la copia locale del database di Active Directory con gli altri controller di dominio. Per cautelarsi, qualunque controller di dominio che è stato non in linea per un tempo maggiore rispetto alla durata dell'oggetto contrassegnato per la rimozione definitiva non deve essere ripristinato; sarà opportuno, invece, crearlo da zero eliminando i vecchi metadati del controller di dominio di Active Directory seguendo i passaggi presenti nell'articolo della Microsoft Knowledge Base 216498 (support.microsoft.com/kb/216498).

Il ripristino USN si verifica anche quando un controller di dominio viene ripristinato utilizzando un metodo non supportato oppure, più spesso, utilizzando uno strumento di creazione di immagini o di clonazione dei dischi. Nel momento in cui si verifica una situazione di questo tipo, il database di Active Directory ripristinato non realizza di essere tornato "indietro nel tempo" perché il metodo di ripristino non era supportato per Active Directory. Con Windows 2000 e la prima versione di Windows Server 2003 era difficile poter individuare un ripristino USN mentre Windows Server 2003 SP1 (e Windows Server 2008 disponibile a breve) dispone di controlli incorporati che consentono di rilevare eventuali ripristini non corretti di un controller di dominio. In queste nuove versioni del sistema operativo, un controller di dominio registrerà l'ID evento 1115, 2095, 2103 e 2110 nel registro eventi dei servizi di directory. Il testo di questi eventi, oltre ai passaggi necessari per il ripristino USN, sono rintracciabili nell'articolo della Knowledge Base 875495 (support.microsoft.com/kb/875495) per Windows Server 2003. È possibile trovare ulteriori informazioni sulla gestione del ripristino USN in Windows 2000 nell'articolo della Knowledge Base 885875, disponibile all'indirizzo support.microsoft.com/kb/885875.

Aggiornamento del modello multimaster nel 2008

Con la versione imminente di Windows Server 2008, Microsoft ha inserito una leggera modifica al modello multimaster introducendo il Controller di dominio di sola lettura (RODC, Read-Only Domain Controller). Il RODC è stato progettato principalmente per le distribuzioni alle succursali o per qualunque scenario in cui non si dispone in sede di personale IT dedicato e in cui è necessario effettuare operazioni aggiuntive per garantire l'integrità di un controller di dominio particolare. Sebbene potremmo dedicare un intero articolo per approfondire tutti i dettagli tecnici del RODC, riesaminiamo i punti principali di cui è necessario essere a conoscenza.

Come indica il nome stesso, la copia del database di Active Directory che si trova in un RODC è di sola lettura. È possibile connettersi a un RODC per leggere tutte le informazioni desiderate, ma non sarà possibile eseguire alcuna operazione di scrittura.

In secondo luogo, un RODC non esegue repliche in uscita. Si tratta di una differenza fondamentale rispetto al modello di replica multimaster di cui abbiamo discusso fino a questo punto. Un RODC riceverà la replica in ingresso dagli altri controller di dominio di Windows Server 2008 scrivibili, ma non replicherà tutte le informazioni al di fuori del controller di dominio. In questo modo viene a crearsi un ulteriore livello di protezione che, nel caso in cui un utente malintenzionato fosse in grado di modificare Active Directory dal RODC, tali modifiche non verrebbero diffuse in tutto l'ambiente.

Probabilmente, la cosa più interessante di tutte è che il RODC non replica le password dell'utente per impostazione predefinita. Quando il database di Active Directory viene replicato in ingresso a un RODC da un controller di dominio scrivibile, tutti gli oggetti utente vengono replicati senza le informazioni sulla password dell'utente. In questo modo viene fornito un ulteriore livello di protezione in una succursale, in maniera tale che se a un controller di dominio "gli crescono le gambe e scappa via", il disco rigido non contiene alcuna informazione sulla password. Nel loro insieme, queste differenze con l'idea originale della replica di Active Directory multimaster creano un modello migliorato per la protezione dei controller di dominio nelle filiali o in altre posizioni remote.

Laura E. Hunter è stata insignita per quattro volte del premio Microsoft MVP per l'area Windows Server Networking. Lavora da oltre 10 anni nel settore IT ed è autrice o coautrice di numerosi libri, articoli e white paper, tra cui Active Directory Cookbook, Second Edition (O'Reilly, 2006).

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