CHAPTER 22

Sistema operativo

Pianificazione del processo di migrazione da Windows NT a Windows 2000

White Paper

In sintesi

In questo documento vengono delineati i processi di pianificazione e le considerazioni relative alla migrazione da domini Microsoft( Windows NT( a Microsoft Windows( 2000. Grazie ai nuovi strumenti, utility e tecnologie di Windows 2000, possibile eseguire rapidamente la migrazione di utenti e computer senza compromettere l'accesso alle risorse.

1999 Microsoft Corporation. Tutti i diritti riservati.

Le informazioni contenute in questo documento rappresentano la posizione corrente di Microsoft Corporation in relazione alle questioni discusse alla data della pubblicazione. Poich Microsoft deve rispondere a condizioni di mercato in continua evoluzione, tali informazioni non devono essere interpretate come impegno da parte di Microsoft, che non pu garantire l'esattezza di alcuna delle informazioni presentate in seguito alla data della pubblicazione.

Questo white paper ha carattere esclusivamente informativo. IN QUESTO DOCUMENTO, MICROSOFT NON FORNISCE ALCUNA GARANZIA, ESPRESSA O IMPLICITA.

Microsoft, Active Desktop, BackOffice, the BackOffice logo, MSN, Windows e WindowsNT sono marchi commerciali o registrati di Microsoft Corporation negli Stati Uniti e/o in altri paesi.

Gli altri nomi di prodotti e societ citati in questo documento sono marchi commerciali dei rispettivi proprietari.

Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA

0399

SOMMARIO

1White Paper

SOMMARIO3Introduzione1DEfinizione del percorso di migrazione2Obiettivi della migrazione2Concetti alla base della migrazione4Aggiornamento dei domini5Implicazioni dell'aggiornamento dei domini5Ristrutturazione dei domini28Quando eseguire la ristrutturazione29Perch eseguire la ristrutturazione30Implicazioni della ristrutturazione dei domini30CHECKlist47Scelta di effettuare l'aggiornamento47Scelta di effettuare la ristrutturazione48riepilogo49Ulteriori informazioni49

Introduzione

Questo white paper si propone come guida alle procedure di pianificazione della migrazione da WindowsNT 3.51 e WindowsNT4.0 a Windows 2000in un contesto aziendale.

L'obiettivo di questo white paper la pianificazione della definizione dello spazio dei nomi Active Directory grazie all'aggiornamento dei domini di Windows NT. Per eseguire questa operazione necessario aver gi eseguito la maggior parte delle procedure di pianificazione dello spazio dei nomi Active Directory. DEfinizione del percorso di migrazione

Nel corso di qualsiasi processo di pianificazione necessario prendere decisioni importanti. Quando si pianifica la migrazione, tali decisioni determinano la disponibilit di funzioni specifiche del sistema operativo.

In questa sezione vengono illustrati alcuni aspetti prioritari della pianificazione, ovvero:

Possibili obiettivi della migrazione

Concetti alla base della migrazione che permettono una migliore comprensione delle decisioni da prendere in fase di elaborazione del prcorso di migrazione e dei loro effetti sugli obiettivi perseguiti.

Alla fine della sezione saranno disponibili le informazioni necessarie per completare la mappa della migrazione e identificare alcune aree di rischio all'interno del progetto.

Obiettivi della migrazione

Gli obiettivi della migrazione possono essere di carattere aziendale o correlati allo stesso processo di migrazione.

Nella maggior parte dei casi sono gli obiettivi di carattere aziendale a determinare la decisione iniziale riguardante la migrazione. Gli obiettivi di questo tipo richiedono alcune scelte relative all'implementazione e possono essere utilizzati per valutare le alternative possibili. In genere viene elaborata una tabella di conformit che nelle fasi successive viene utilizzata per identificare le tecnologie e le funzioni del prodotto da adottare nella piattaforma finale.

Gli obiettivi correlati alla migrazione riguardano i risultati della migrazione stessa e possono essere influenzati da fattori quali le eventuali ripercussioni sui sistemi di produzione, sulle prestazioni finali del sistema e sul tempo medio tra i guasti. Tali obiettivi possono determinare le modalit di formulazione dei piani di controllo e dei criteri di accettazione.

consigliabile che il processo di migrazione miri principalmente a passare il pi presto possibile a Windows2000 in modalit nativa per sfruttare al massimo i vantaggi offerti dalle tecnologie di Windows2000.

Tabella 1. Obiettivi di carattere aziendaleObiettivoFunzioneVantaggi

Migliore gestibilitTrust Kerberos transitiviLe relazioni di trust transitive o implicite riducono la necessit di trust complessi o espliciti.

Individuazione e amministrazione delle risorse Active DirectoryActive Directory offre un'unica serie uniforme di interfacce per l'esecuzione di attivit amministrative comuni e l'individuazione di utenti e risorse all'interno dell'azienda.

Unit organizzative (OU) di Active Directory possibile delegare i diritti amministrativi a livello di OU.

Gruppi di protezione Active DirectoryIn Windows2000 disponibile un maggior numero di gruppi con un ambito pi ampio.

Maggiore scalabilitArchitettura di memoria a 64 bitWindows2000 Server consente di accedere a 32GB di memoria in processori a 64 bit.

Scalabilit di Active DirectoryActive Directory consente livelli di scalabilit maggiori grazie alla possibilit di memorizzare milioni di oggetti.

Autenticazione KerberosAumenta la velocit delle prestazioni riducendo i carichi del server al momento della connessione.

Microsoft Management Console (MMC)MMC standardizza l'aspetto del set di strumenti per la gestione aziendale.

Migliore protezioneCriteri di gruppoCriteri di gruppo consente agli amministratori di esercitare un controllo capillare degli utenti che hanno accesso a particolari workstation, dati e applicazioni.

Security Configuration Tool Set (SCTS)SCTS un set di snap-in MMC che permettono di definire i modelli di configurazione della protezione degli oggetti (ad esempio hive del registro di sistema e file system), e dei criteri di protezione (ad esempio la password).

InstallazioneDurante l'installazione di Windows2000 vengono applicate migliori impostazioni di protezione.

Maggiore disponibilitReplica multi-master di Active DirectoryConsente una maggiore disponibilit del sistema in caso di errore di un controller di dominio (DC-Domain Controller).

Nota Tutti gli obiettivi elencati nella Tabella 1 richiedono l'installazione di Windows2000Server.

Tabella 2. Obiettivi correlati alla migrazioneObiettivoImplicazioni per il processo di migrazione

Minimo disturbo all'ambiente di produzione L'accesso dell'utente a dati e risorse deve essere mantenuto durante e in seguito alla migrazione.

L'accesso dell'utente alle applicazioni deve essere mantenuto durante e in seguito alla migrazione.

L'ambiente familiare all'utente deve essere mantenuto durante e in seguito alla migrazione.

Sovraccarico amministrativo minimo La migrazione degli account utente deve essere eseguita con la massima semplicit.

Gli utenti devono mantenere le rispettive password.

Gli amministratori dovranno eseguire un numero minimo di interventi diretti sulle workstation.

Non deve essere necessario impostare nuove autorizzazioni di accesso alle risorse.

Accesso ottimizzato alle funzioniL'azienda deve poter accedere il pi presto possibile alle principali funzioni della nuova piattaforma.

Protezione del sistemaLa migrazione non deve influire sui criteri di protezione se non migliorandoli.

Concetti alla base della migrazione

Per ottenere l'infrastruttura desiderata possibile procedere in due modi:

Aggiornamento dei domini, spesso denominato in-place update Ristrutturazione dei domini, talvolta denominata consolidamento o compressione dei dominiL'aggiornamento e la ristrutturazione non si escludono reciprocamente; alcune organizzazioni devono eseguire prima l'aggiornamento e quindi la ristrutturazione, mentre altre devono procedere nell'ordine inverso.

Aggiornamento dei domini

L'aggiornamento a Windows 2000 Server rappresenta la modalit di migrazione pi semplice e che comporta i rischi minori.

L'aggiornamento dei domini pu essere definito come il processo di aggiornamento da Windows NT 4.0 a Windows 2000 Server del software nel PDC(Primary Domain Controller) di un dominio e di alcuni o tutti i BDC (Backup Domain Controller).

Poich Windows 2000 stato progettato per supportare reti miste con interoperabilit completa tra Windows9x, WindowsNT4.0 e Windows2000, per avvalersi delle funzioni di Windows2000 non necessario aggiornare tutti i sistemi del dominio. Sulla base di questa premessa, l'aggiornamento del PDC deve essere considerato semplicemente come la prima fase del processo, in quanto possibile ottenere ulteriori vantaggi aggiornando successivamente i BDC e quindi i server detti member.

Trattandosi dell'aggiornamento di un sistema operativo e non di un'installazione ex-novo, verranno mantenuti la struttura dei domini, gli utenti e i gruppi esistenti abilitando al contempo nuove funzioni di Windows 2000. Infatti, la principale differenza tra aggiornamento e consolidamento risiede nel fatto che nel primo caso viene mantenuta la struttura esistente dei domini.

Dopo aver completato l'aggiornamento e aver ottenuto l'accesso alle funzioni e agli strumenti di gestione avanzati di Windows 2000, pu essere necessario ristrutturare i domini. Bisogna tenere presente che la ristrutturazione non un'operazione banale e che, al contrario, richiede ulteriori interventi di pianificazione e implementazione, come illustrato nella relativa sezione pi avanti in questo documento. Se la modifica strutturale rappresenta uno dei principali obiettivi della migrazione, pu essere utile adottare un metodo che preveda l'esecuzione della ristrutturazione durante la migrazione.

Implicazioni dell'aggiornamento dei domini

L'aggiornamento rappresenta la modalit di migrazione pi semplice e che comporta i minori rischi in quanto consente di mantenere la maggior parte delle impostazioni del sistema, preferenze e installazioni di programmi. In questa sezione verranno presi in esame gli effetti reali dell'aggiornamento sui DC e sui principali criteri di protezione e verr spiegata l'importanza di tali elementi ai fini delle scelte di pianificazione.

Installazione guidata di Active Directory (DCPromo.exe)

Dopo aver attivato la sincronizzazione di tutti i BDC del dominio, grazie alla quale vengono integrate le ultime modifiche apportate al PDC, possibile iniziare il processo di aggiornamento dei domini di account mediante l'aggiornamento del PDC.

Dopo aver installato il sistema operativo di base del PDC, il programma di installazione rileva l'aggiornamento del DC e richiede all'amministratore di installare Active Directory nel server eseguendo automaticamente il programma DCPROMO.

Grazie a DCPROMO, l'amministratore ha la possibilit di creare la prima struttura ad albero del nuovo insieme di strutture-foresta, creare una nuova struttura in un insieme esistente, creare una replica di un dominio esistente o installare un dominio figlio. La scelta dipende dal risultato del processo di pianificazione dello spazio dei nomi.

Nota In questo documento non viene fornita una descrizione dettagliata del processo. Infatti, necessario considerare anche operazioni come il backup del dominio per far fronte all'eventuale insorgenza di complicanze. Inoltre, prima di procedere alla sincronizzazione e all'aggiornamento, pu essere necessario aggiungere al dominio un BDC supplementare da utilizzare non in linea per la durata del processo di aggiornamento. Per ulteriori informazioni, consultare il manuale Deployment Planning Guide.

PDC di Windows NT

Durante il processo di installazione di Active Directory, il contenuto del database di account di Windows NT e del database SAM (Security Account Manager) viene copiato in Active Directory. Tali oggetti rappresentano i criteri di protezione (account utente, gruppi locali e globali e account dei computer).

Dopo aver aggiornato il PDC e installato Active Directory, il dominio viene eseguito in Windows 2000 in modalit mista. Per una descrizione pi dettagliata della modalit mista e nativa, vedere la sezione Modalit mista e modalit nativa, pi avanti in questo documento.

A partire da questo momento, il PDC di Windows 2000 Server utilizzer Active Directory per memorizzare gli oggetti. Il PDC totalmente compatibile con le versioni precedenti in quanto durante il processo di replica espone i dati ai BDC di Windows NT sotto forma di archivio in formato lineare, come dimostrato dai seguenti elementi:

Il PDC viene visualizzato come DC di Windows 2000 per gli altri computer Windows 2000 e come PDC di Windows NT per i computer non ancora aggiornati.

possibile continuare a utilizzare il PDC per creare nuovi criteri di protezione e replicare le modifiche apportate nei BDC di Windows NT Server.

Le workstation Windows NT e Windows 9x possono utilizzare il PDC come server di accesso.

Se il PDC di Windows 2000 Server non in linea o comunque non pi disponibile e nel dominio non esistono altri DC di Windows 2000, possibile convertire in PDC un BDC di Windows NT.

Effetti dell'aggiornamento sul controllo degli accessi

Il principale problema derivante dallo spostamento dei criteri di protezione in Active Directory nell'ambito del processo di aggiornamento del PDC rappresentato dall'effetto esercitato da questa operazione sull'accesso alle risorse.

SID (Security Identifier)

Il modello di protezione di Windows NT (su cui si basa la protezione di Windows NT e Windows 2000) associa un SID a ciascun oggetto account, ad esempio utenti, gruppi, computer e trust di dominio. I SID sono valori univoci di ciascun dominio che vengono generati al momento della creazione di un utente o di un gruppo o della registrazione di un computer o di un trust nel dominio stesso.

I componenti di un SID rispettano una convenzione gerarchica: un SID include parti che identificano il numero di revisione, l'autorit (ad esempio il dominio) che ha emesso il SID e un numero variabile costituito da valori che definiscono l'autorit secondaria, detto RID (Relative Identifier), che identifica in modo univoco il criterio di protezione relativo all'autorit in questione.

Anche se esistono SID ben noti che identificano gruppi e utenti generici in tutti i sistemi, in questo documento verranno presi in esame soprattutto i criteri di protezione che vengono definiti nel contesto di un dominio e che pertanto non possibile spostare tra domini senza dover modificare i relativi SID.

Token di autenticazione e di accesso

Un componente essenziale del modello di protezione di Windows NT rappresentato dall'autenticazione, in base alla quale un utente viene identificato nel dominio grazie alla presentazione delle relative credenziali, in genere sotto forma di nome utente e password. Se ritiene accettabili le credenziali, il sistema crea per l'utente un token di accesso contenente il SID dell'utente (SID principale) e i SID dei gruppi del dominio di cui l'utente membro. A qualsiasi processo creato dall'utente, ad esempio l'esecuzione di un'applicazione, associato il relativo token di accesso.

Il token di accesso viene utilizzato dal sistema per determinare se possibile concedere all'utente l'accesso alle risorse di sistema.

Descrittori autorizzazioni e protezione

La controparte del token di accesso dell'utente il descrittore di protezione associato a risorse come file o stampanti. Ogni descrittore di protezione contiene un ACL (Access Control List) costituito da un elenco di voci ACE (Access Control Entries). Ogni ACE formata da un SID e da un indicatore che segnala se al criterio di protezione identificato dal SID viene concesso o negato l'accesso alla risorsa.

Dalla descrizione precedente si pu osservare che l'effetto dell'aggiornamento sui SID riveste un'importanza fondamentale: qualsiasi modifica apportata ai SID durante il processo di aggiornamento influisce sull'accesso alle risorse.

Durante l'aggiornamento i criteri di protezione rimangono nello stesso dominio in cui sono stati creati e, pertanto, i SID che li identificano rimangono invariati. Di conseguenza, l'aggiornamento non influisce sull'accesso alle risorse.

Effetti dell'aggiornamento sui trust

Figura 1. Esempio del dominio MILGIO.TLD

DCPROMO permette inoltre di installare il software Kerberos. A installazione ultimata, vengono avviati i servizi di autenticazione e il servizio di emissione di ticket. Se l'amministratore ha deciso di utilizzare una struttura esistente, verr stabilita una relazione bidirezionale transitoria tra il trust Kerberos e il dominio padre. Le relazioni di trust create prima dell'aggiornamento del PDC verranno mantenute, anche se sotto forma di trust unidirezionali espliciti di Windows NT.

Infine il DC del dominio padre copia tutte le informazioni sullo schema e la configurazione nel nuovo dominio figlio. Una volta replicate le informazioni necessarie, il dominio aggiornato a tutti gli effetti un membro completamente operativo della struttura di domini di Active Directory, anche se rimane in modalit mista finch l'amministratore non decide di convertirlo nella modalit nativa di Windows 2000.

A questo punto, i client che riconoscono Active Directory, ad esempio le workstation con sistema operativo Windows 2000 Professional o Windows 9x (e in cui in esecuzione il software client Active Directory) possono utilizzare le funzioni di Active Directory ed eseguire operazioni quali la ricerca in cataloghi globali per individuare risorse e persone. I client saranno inoltre in grado di utilizzare le relazioni di trust transitorie esistenti nell'insieme di strutture per accedere alle risorse disponibili al suo interno. La modalit con cui vengono eseguite queste operazioni varia a seconda del fatto che nel client sia installato Windows 2000 o un sistema operativo precedente come Windows NT o Windows 9x, nonch in base allo stato di aggiornamento del dominio di destinazione.

Le risorse della foresta di domini saranno accessibili mediante i trust transitori in cui risiedono:

Domini in modalit nativa

Domini in modalit mista in cui sono stati aggiornati tutti i DC

Domini in modalit mista in cui sono stati aggiornati i DC che rispondono alla richiesta di autenticazione NTML o Kerberos.

In tutti gli altri casi, i client avranno accesso solo alle risorse disponibili mediante gli esistenti trust unidirezionali espliciti di Windows NT, rimasti invariati in seguito all'aggiornamento.

A titolo di chiarimento, di seguito vengono riportati alcuni esempi di funzionamento dell'autenticazione NTLM e Kerberos. Questo scenario illustrato nella precedente Figura 1.

Utilizzo dell'autenticazione NTLM

Si supponga che un utente si connetta al dominio haybuv-acct haybuv.tld, in modalit mista, dalla workstation Windows NT ntws, inclusa nello stesso dominio. L'utente cerca quindi di attivare una connessione di rete a un computer Windows NT Server, nts, nel dominio haybuv-altro.haybuv.tld, un dominio in modalit nativa di Windows 2000. Essendo un client Windows NT, ntws utilizzer il protocollo NTLM.

Nts rileva che il nome del dominio specificato nelle credenziali ricevute, haybuv -acct.haybuv. tld, non incluso nel proprio database di account e, pertanto, invia la richiesta di connessione a un DC del proprio dominio per l'autenticazione. Il DC verifica il nome del dominio e, poich questo non corrisponde al nome del dominio del DC, verifica se si tratta di un dominio trusted. Poich i domini haybuv-acct.haybuv.tld e haybuv-altro.haybuv.tld sono entrambi figli dello stesso dominio principale, haybuv.tld, tra essi esiste un trust transitivo. Pertanto, il DC passa la richiesta di connessione a un DC del dominio trusted. Tale DC autentica il nome utente e la password confrontandola con quelli inclusi nel proprio database di account del dominio e, se le credenziali sono valide, restituisce le informazioni di identificazione dell'account al DC da cui stato contattato, che a sua volta le restituir al server.

A questo punto, il server crea per l'utente un token di rappresentazione contenente il SID dell'utente e i SID degli eventuali gruppi di dominio di cui l'utente membro. Successivamente, il server crea nel contesto di protezione dell'utente un thread di rappresentazione contenente il relativo token e quindi prova ad accedere alla risorsa per conto dell'utente.

Si pu osservare che un client di basso livello appartenente a un dominio in modalit mista pu accedere a un server di basso livello di un altro dominio della struttura utilizzando il protocollo NTLM, a condizione che nel DC del dominio di destinazione venga eseguito Windows 2000 e quindi vengano riconosciuti i trust transitivi. Poich tutte le strutture appartenenti allo stesso insieme sono collegate da trust transitivi, quanto sopra varrebbe anche se i due domini appartenessero a strutture diverse.

Per estensione, ne consegue che se si cerca di accedere a una risorsa residente nel computer Windows NT Server nts nel dominio in modalit mista haybuv-ris1.haybuv -altro.haybuv.tld, a condizione che nel DC a cui il server ha passato la richiesta di connessione venga eseguito Windows 2000, sarebbe possibile accedere alla risorsa per mezzo di un trust transitivo all'interno dell'insieme di strutture.

Utilizzo dell'autenticazione Kerberos

Si supponga ora che un utente cerchi di connettersi al dominio haybuv-acct.haybuv.tld come nell'esempio precedente, ma questa volta dal computer w2kpro appartenente allo stesso dominio, in cui in esecuzione Windows 2000. L'utente desidera attivare una connessione di rete a un computer Windows 2000 Server, w2ksrv, nel dominio haybuv-altro.haybuv.tld. Essendo un client Windows 2000, w2kpro prover a utilizzare il protocollo Kerberos.

Kerberos un protocollo basato su ticket. Al momento della connessione iniziale al dominio, questo protocollo prevede l'emissione agli utenti di TGT (Ticket Granting Ticket) da parte del servizio di emissione di ticket del KDC (Key Distribution Center) in cui viene eseguito il DC di Windows 2000. I TGT contengono informazioni relative all'autenticazione dell'utente cifrate in base alla chiave master del dominio, che quindi pu essere restituita al DC nell'ambito delle richieste di ulteriori ticket di sessione per la connessione di altri server al dominio. Una volta che l'utente ha ottenuto un TGT, le verifiche successive sono rapide ed efficienti in quanto per verificare le credenziali dell'utente sufficiente che il DC decifri il TGT. I ticket di sessione sono analoghi ai TGT, ma vengono cifrati in base a una chiave condivisa dal server e dal DC.

Come NTLM, anche il protocollo Kerberos pu operare tra domini diversi. Un client appartenente a un dominio pu richiedere l'autenticazione in un server di un altro dominio se tra i due domini stata stabilita una relazione di trust. In questo caso, infatti, vengono scambiate le chiavi interdominio. Il servizio di autenticazione di ciascun dominio utilizza la propria chiave interdominio per decifrare i ticket per il servizio di emissione di ticket dell'altro dominio.

Per accedere a un server di un dominio remoto, un client deve richiedere al DC del dominio di origine un ticket di riferimento, ovvero un TGT che il client stesso presenter al servizio di emissione di ticket del DC del dominio remoto. Il DC locale risponde inviando al client un TGT cifrato in base alla chiave interdominio del DC remoto.

Il client presenta il TGT di riferimento al servizio di emissione di ticket del DC remoto, richiedendo un ticket per un server del proprio dominio. Il DC remoto decifra il TGT del client in base alla propria chiave interdominio. Se il TGT viene decifrato correttamente, il DC remoto pu essere certo che il TGT stato emesso da un'autorit trusted e quindi concede al client un ticket per il server richiesto.

Nella Figura 1 si pu osservare che, poich haybuv-acct.haybuv.tld e haybuv-altro.haybuv.tld sono figli dello stesso dominio principale e sono legati da un trust transitivo, tra i due domini possibile creare un percorso di trust. Quando riceve il TGT di riferimento, il DC del dominio di destinazione verifica se questo dispone di una chiave condivisa per il server in questione. In questo caso il DC emetter un ticket di sessione per il client. Poich w2ksrv un computer Windows 2000, la chiave condivisa esiste e pertanto possibile emettere un ticket per w2kpro.

Come si pu osservare, i principali fattori in questo scenario sono l'esistenza di un DC nel dominio di destinazione in cui in esecuzione il servizio di emissione di ticket di Kerberos e l'esistenza di una chiave condivisa dal DC e dal server. Nei DC di Windows 2000 il servizio Kerberos viene installato durante la procedura di installazione di Active Directory e l'inserimento di un server membro in un dominio Windows 2000 comporta la creazione di una chiave condivisa. Di conseguenza, w2kpro deve essere in grado di accedere a w2ksrv. haybuv-ris1.haybuv -altro.haybuv.tld utilizzando il protocollo Kerberos, a condizione che sia disponibile un DC di Windows 2000 per l'emissione del ticket di sessione.

Se w2kpro cerca di accedere a una risorsa residente in un computer Windows NT come nts.haybuv -ris1.haybuv -altro.haybuv.tld, l'autenticazione Kerberos non viene eseguita e il client cercher di eseguire l'autenticazione NTLM, descritta nella sezione precedente.

Aggiornamento e domini di risorse

Un dominio di risorse un particolare tipo di dominio creato per contenere gli account di risorse come server e workstation. I domini di risorse sono stati creati in Windows NT fondamentalmente per offrire una soluzione a due situazioni:

Limitazione delle dimensioni del SAM. In WindowsNT la dimensione massima consigliata per il database di account SAM 40 megabyte (MB). In un'organizzazione in cui sono distribuiti numerosi server e workstation e in cui sono presenti molti gruppi di protezione, questo pu equivalere a un numero notevolmente inferiore ai 40000 account di cui in alcuni casi stata dichiarata la necessit. Per limitare le dimensioni del database al di sotto di tale numero, consigliabile memorizzare gli account utente e dei computer in domini separati, denominati rispettivamente dominio di account o master e dominio di risorse.

In genere i domini di risorse vengono creati come domini di secondo livello, con trust unidirezionali (relazioni di trust) verso un unico dominio di account (questa topologia viene denominata modello del dominio master) oppure verso pi domini di account (il modello a pi domini master).

Disponibilit di funzioni amministrative locali. In un'organizzazione decentralizzata con pi sedi dislocate in diverse posizioni geografiche, spesso opportuno disporre di personale locale autorizzato ad amministrare le risorse. Per assegnare questo tipo di responsabilit in Windows NT, consigliabile creare domini di risorse con una struttura amministrativa autonoma. Come nel caso precedente, in questo modo si producono strutture a uno o pi domini master con trust unidirezionali verso i domini di account dell'organizzazione.

Grazie alla natura unidirezionale dei trust, per impostazione predefinita gli amministratori dei domini di risorse possono esercitare le funzioni amministrative esclusivamente nell'ambito del dominio di risorse.

Prendendo in esame gli effetti dell'aggiornamento di un dominio di risorse importante chiedersi a quale dei due modelli descritti ha fatto ricorso lo sviluppatore per determinare la struttura del dominio. Se il dominio stato creato per far fronte alla seconda situazione, opportuno considerare le ripercussioni dell'aggiornamento di un dominio di risorse sul modello amministrativo; infatti, se ci si limita ad aggiornare il dominio di risorse e a utilizzare l'insieme di strutture esistente, viene creato un trust transitorio bidirezionale tra il dominio di risorse figlio e il dominio padre.

Se gli amministratori locali non sono molto esperti o se non si intende assegnare loro diritti amministrativi per l'insieme di strutture di Windows 2000, pu essere necessario considerare le seguenti possibilit:

Aggiornamento del dominio all'interno dell'insieme di strutture e utilizzo delle funzioni di delega di Windows 2000. Controllare i gruppi amministrativi presenti nel dominio di risorse e rimuovere quelli che non svolgono funzioni di amministratore nel dominio master. Se si dispone soltanto di amministratori dei domini di risorse locali, necessario aggiungere uno o pi amministratori dei domini master, che saranno in grado di amministrare il dominio durante l'aggiornamento. Come ulteriore precauzione, possibile assicurarsi che gli amministratori dei domini di risorse non abbiano accesso amministrativo ai DC utilizzando account di computer locali.

Dopo aver aggiornato il PDC, possibile creare nel dominio un nuovo gruppo locale in cui inserire gli amministratori delle risorse e quindi aggiungere gli utenti precedentemente rimossi dai gruppi amministrativi, nonch i gruppi amministrativi modificati.

Dopo aver aggiornato il PDC, possibile utilizzare le funzioni di delega amministrativa di Windows 2000 per conferire l'autorit appropriata al nuovo gruppo di amministratori delle risorse.

Aggiornamento del dominio all'interno di un nuovo insieme di strutture. possibile decidere di aggiornare il dominio di risorse come nuova struttura di un nuovo insieme di strutture, mantenendo il collegamento con il dominio di account utilizzando il trust esplicito preesistente con tale dominio; come i trust espliciti di Windows NT, il trust utilizzato sar unidirezionale e non transitivo. In questo modo possibile rispecchiare in modo efficace la struttura precedente all'aggiornamento.

Ristrutturazione in OU. Un'ulteriore alternativa pu essere rappresentata dalla modifica della struttura di domini eseguita successivamente riunendo i domini di risorse come OU del dominio master aggiornato. Ovviamente, questo modo di procedere influirebbe in misura significativa sull'ordine di aggiornamento dei domini.

Aggiornamento e amministrazione

Dopo aver aggiornato il PDC a Windows 2000 Server e aver installato Active Directory, l'amministratore pu iniziare a utilizzare i nuovi strumenti disponibili in Windows 2000 Server per creare nuovi oggetti esclusivi di Active Directory, ad esempio le unit organizzative (OU).

Se si creano OU, possibile iniziare a organizzare il dominio inserendovi gli oggetti desiderati. Questa struttura visibile solo per i computer in cui installato il software client di Active Directory. Negli altri computer le OU non sono visibili e il dominio risulta invariato. Il PDC continuer ad esporre gli oggetti come archivio lineare ai client di basso livello.

Un amministratore che utilizza un client in cui non installato Active Directory potr utilizzare solo gli strumenti amministrativi esistenti.

Modalit mista e modalit nativa

Figura 2. Fasi dell'aggiornamento

Modalit mistaDal momento in cui viene aggiornato il PDC al momento in cui l'amministratore decide di attivare nel dominio la modalit nativa di Windows 2000, il dominio in modalit mista. Tale modalit consente la massima compatibilit con le versioni precedenti del sistema operativo. importante sottolineare che la modalit mista si riferisce solo all'infrastruttura di autenticazione di un dominio, ovvero, in altri termini, ai controller di dominio. Anche se un dominio include solo DC di Windows 2000 ed stato attivato in modalit nativa, nel dominio possono esistere client e server in cui vengono eseguite versioni precedenti di Windows NT e in cui installato Windows 9x. Questo tipo di ambiente noto come ambiente misto.

possibile lasciare il dominio in modalit mista a tempo indeterminato, anche se sono stati aggiornati tutti i BDC del dominio e il PDC.

Nella Tabella 3, riportata di seguito, vengono indicate le funzioni di Windows2000 disponibili in modalit mista e quelle che possibile utilizzare solo passando alla modalit nativa. In caso di dubbi sul passaggio alla modalit nativa, possibile verificare se gli obiettivi della migrazione risulterebbero compromessi da un'eventuale permanenza in modalit mista e se esistono alternative accettabili.

In generale, gli unici motivi per rimanere in modalit mista sono i seguenti:

Impossibilit di aggiornare i BDC. In questa situazione impossibile aggiornare i BDC o abbassarli al livello di server membri. Questo pu succedere, ad esempio, in presenza di applicazioni che devono essere eseguite in un BDC, ma che per qualsiasi motivo non possono essere eseguite in Windows 2000.

Inadeguatezza della protezione fisica dei BDC. Uno dei punti chiave di qualsiasi discussione sulla pianificazione dei domini sicuramente la protezione. Un aspetto fondamentale della protezione rappresentato dalla protezione fisica dei computer, a cui possibile accedere facilmente e che sono vulnerabili a qualsiasi violazione. A questo proposito, importante considerare la differenza tra l'aggiornamento single-master del SAM eseguito dal solo PDC e l'aggiornamento multimaster Active Directory del database di account eseguito da tutti i DC.

Considerando la natura single-master degli aggiornamenti delle directory di Windows NT, non dovrebbero sorgere particolari problemi di protezione dei BDC. In questo caso, necessario considerare questo aspetto durante l'aggiornamento dei BDC in DC di Windows 2000. Se invece non possibile aggiornare adeguatamente la protezione dei BDC, durante l'aggiornamento si pu provvedere ad abbassare di livello il BDC convertendolo in server membro e quindi aggiungere un nuovo DC di Windows 2000 in una diversa posizione oppure riconsiderare la struttura di domini proposta.

Necessit di fallback a Windows NT. Da un esame delle precedenti considerazioni risulta evidente che una delle principali caratteristiche della modalit mista l'elevato grado di compatibilit con le versioni precedenti. La modalit mista offre il vantaggio di consentire l'aggiunta di nuovi BDC di Windows NT al dominio in caso di problemi. In questa situazione, dopo aver aggiunto il BDC al dominio, possibile risincronizzare il database di account. A questo punto, se il dominio non include DC di Windows 2000, possibile promuovere il BDC a PDC. possibile pianificare un eventuale fallback o un intervento di recupero, ma a un certo punto auspicabile passare completamente al nuovo ambiente.

Modalit nativa

Dopo aver aggiornato tutti i DC possibile passare dalla modalit mista alla modalit nativa. Durante il passaggio si verificano diversi eventi:

Poich il dominio utilizza solo la replica multimaster di Active Directory tra i DC, viene disattivato il supporto per la replica Netlogon.

Una volta disattivata la replica Netlogon, non pi possibile aggiungere nuovi BDC di Windows NT al dominio.

Essendo stata attivata la replica multimaster, il precedente PDC non pi il PDC master del dominio e tutti i DC possono ora eseguire aggiornamenti delle directory. Un elemento che spesso genera confusione la persistenza del ruolo di emulazione del PDC. Infatti, nonostante la natura multimaster di Active Directory, Windows 2000 include numerosi ruoli denominati FSMO (Flexible Single-Master Operations), tra cui PDC Emulator. In genere, il precedente PDC continua a fungere da PDC Emulator FSMO, e in un ambiente in modalit nativa ci significa che le modifiche della password vengono replicate al suo interno principalmente da altri DC.

Vengono attivati i tipi di gruppo di Windows2000, ad esempio i gruppi universali e locali al dominio, e la nidificazione dei gruppi stessi.

Il passaggio alla modalit nativa non viene effettuato automaticamente eseguendo DCPROMO, ma deve essere abilitato dall'amministratore attraverso l'interfaccia amministrativa.

Anche se possibile trarre grandi vantaggi aggiornando il PDC e i BDC e rimanendo in modalit mista, in questa modalit non sono disponibili alcune funzioni molto utili come i gruppi universali o la nidificazione dei gruppi.

Il passaggio alla modalit nativa deve essere effettuato il pi presto possibile.

Passaggio alla modalit nativa

Il passaggio dalla modalit mista alla modalit nativa del dominio pu essere eseguito molto rapidamente, ma non pu essere annullato. Pertanto, per decidere quando effettuarlo necessario tenere presente tutti gli aspetti precedentemente descritti. Evitare di modificare la modalit del dominio se si dispone di DC di Windows NT.

Per modificare la modalit del dominio.

1. Aprire lo snap-in Domini e trust di Active Directory e fare clic con il pulsante destro del mouse sul dominio che si desidera amministrare nel riquadro sinistro della visualizzazione della struttura.

2. Verr visualizzato un menu di scelta rapida. Scegliere Propriet per visualizzare una finestra di dialogo in cui sono disponibili alcune schede, illustrate nella Figura 3.

3. Nella scheda Generale fare clic su Cambia modalit (Change Mode).

Figura 3. Finestra di dialogo in cui modificare la modalit del dominio.

Tabella 3. Disponibilit delle funzioni di Windows 2000 in modalit mista

ObiettivoFunzioneDisponibile in modalit mista?

Migliore gestibilitTrust transitivi KerberosS (vedere la precedente sezione Effetti dell'aggiornamento sui trust).

Active DirectoryS

Unit organizzative (OU) di Active DirectoryS, ma sono visibili solo utilizzando gli strumenti amministrativi di Windows 2000. Le OU non possono essere amministrate dai server membri n dai BDC di Windows NT.

Nuovi gruppi di protezione di Active DirectoryNo, sono disponibili solo gruppi globali e locali.

Installazione di WindowsS

Maggiore scalabilitArchitettura di memoria a 64 bitS

Scalabilit di Active DirectoryS, ma solo quando tutti i BDC sono stati aggiornati ed eseguono Active Directory. Utilizzare questa funzione con estrema cautela in quanto possibile aggiungere nuovi BDC di Windows NT anche quando il dominio in modalit mista. Questa funzione pu rivestire un ruolo importante ai fini della pianificazione del fallback e non deve essere compromessa.

Autenticazione KerberosS, per i computer Windows 2000.

Microsoft Management Console (MMC)S

Protezione miglioreCriteri di gruppoS, per i DC e altri computer Windows 2000 del dominio.

Security Configuration Manager (SCM)S.

Maggiore disponibilitReplica multimaster di Active DirectoryS, tra PDC e BDC aggiornati.

Gruppi di Windows2000

Nella sezione precedente stata citata la nuova funzionalit dei gruppi di protezione di Windows 2000.

Windows 2000 supporta quattro tipi di gruppi di protezione:

Locali

Locali al dominio

Globali

Universali

Gruppi locali

I gruppi locali sono sempre esistiti in Windows NT. Per quanto riguarda le regole di appartenenza, questi gruppi possono includere membri provenienti da qualsiasi punto dell'insieme di strutture, altri insiemi di strutture trusted e perfino domini trusted di basso livello. Per quanto riguarda le autorizzazioni di accesso alle risorse, tuttavia, la validit di questi gruppi limitata a livello di computer in quanto possono essere utilizzati solo per concedere autorizzazioni per il computer in cui risiedono.

Fanno eccezione i gruppi locali creati nei PDC di versioni precedenti di Windows NT che, grazie alla replica del SAM del dominio tra i BDC, possono essere condivisi tra PDC e BDC. In modalit mista, i gruppi locali hanno funzionalit simili in Windows NT e Windows 2000, mentre in modalit nativa i gruppi locali di un DC diventano gruppi locali al dominio, descritti nella sezione successiva.

In genere i gruppi locali vengono utilizzati per concedere l'accesso ad-hoc alle risorse di un computer locale.

Gruppi locali al dominio

I gruppi locali al dominio sono una nuova funzione di Windows 2000, bench simili per concezione e utilizzo ai gruppi locali creati nei PDC di un dominio di Windows NT 4.0 (precedentemente descritti).

I gruppi locali al dominio sono disponibili solo nei domini in modalit nativa. Per quanto riguarda le regole di appartenenza, possono includere membri provenienti da qualsiasi parte dell'insieme di strutture e perfino domini trusted di basso livello. Per quanto riguarda le autorizzazioni di accesso alle risorse, i gruppi locali al dominio hanno validit solo a livello di dominio e pertanto possono essere utilizzati solo per concedere autorizzazioni nell'ambito del dominio in cui risiedono. A differenza dei gruppi locali, possono essere utilizzati in qualsiasi computer Windows NT all'interno del dominio in cui sono stati creati.

In genere i gruppi locali al dominio vengono utilizzati per raccogliere criteri di protezione nell'intero insieme di strutture per controllare l'accesso alle risorse del dominio.

Gruppi globali

I gruppi globali di Windows 2000 equivalgono ai gruppi globali di Windows NT. Per quanto riguarda le regole di appartenenza, hanno validit a livello di dominio, ma possono ricevere autorizzazioni in qualsiasi dominio, anche in altri insiemi di strutture e domini di basso livello, a condizione che esista una relazione di trust.

Gruppi universali

I gruppi universali hanno validit a livello di insieme di strutture, ovvero possono includere membri provenienti da qualsiasi dominio di Windows 2000 presente nell'insieme stesso e ricevere autorizzazioni in qualsiasi dominio, anche appartenente ad altri insiemi di strutture, a condizione che esista una relazione di trust.

Anche se i gruppi universali possono includere membri appartenenti a domini in modalit mista residenti nello stesso insieme di strutture, tali gruppi non possono essere aggiunti al token di accesso dei membri dei domini in questione in quanto i gruppi universali non sono disponibili in modalit mista.

Pur essendo possibile aggiungere utenti a un gruppo universale, consigliabile limitare l'appartenenza ai gruppi globali.

I gruppi universali sono disponibili solo nei domini in modalit nativa.

Utilizzo dei gruppi universali

Per i gruppi universali sono previste numerose importanti modalit di utilizzo, tra cui la creazione di gruppi che eseguono funzioni comuni all'interno di un'azienda, ad esempio team virtuali. In una grande societ probabile che l'appartenenza a questi team sia di livello nazionale e perfino internazionale, ma sicuramente possibile includervi membri a livello dell'insieme di strutture, con un'analoga distribuzione delle risorse disponibili. In questa situazione i gruppi universali possono essere utilizzati come contenitori di gruppi globali appartenenti a ciascuna affiliata o divisione e le risorse del team corrispondente al gruppo universale vengono protette da un'unica ACE (Access Control Entry).

Quando si utilizzano i gruppi universali, necessario tenere presente una distinzione importante. Infatti, i gruppi locali e globali sono elencati nel Catalogo globale (Global Catalog, GC), mentre i loro membri non vi compaiono. Al contrario, in tale catalogo vengono elencati sia i gruppi universali che i rispettivi membri, un fattore che influisce in misura considerevole sul traffico di replica del GC. I gruppi universali vanno utilizzati con estrema cautela. In linea di massima, se l'intera rete prevede una connettivit a velocit elevata, possibile convertire tutti i gruppi in gruppi universali, con il vantaggio di non dover preoccuparsi di gestire gruppi globali e locali al dominio. Se invece si utilizza una rete WAN, possibile migliorare le prestazioni in diversi modi grazie all'utilizzo di gruppi globali e locali al dominio.

Se si utilizzano gruppi globali e locali al dominio, inoltre possibile designare gruppi di utilizzo diffuso che raramente vengono convertiti in gruppi universali.

Gruppi universali e token di accesso

Durante la discussione sull'appartenenza ai gruppi universali si accennato al fatto che possono contenere membri appartenenti a domini in modalit mista, il cui token di accesso comunque non include il SID del gruppo universale. Questo succede in ragione delle modalit di creazione dei token di accesso in Windows 2000.

Quando un utente si connette a un dominio in modalit nativa di Windows 2000 e viene autenticato, la LSA (Local Security Authority) del DC in cui avvenuta l'autenticazione recupera le appartenenze dell'utente a gruppi globali. La LSA passa quindi tali informazioni alla workstation, in cui vengono utilizzate per creare il token di accesso dell'utente. Contemporaneamente, la LSA richiede al GC le appartenenze dell'utente a gruppi universali, informazioni che vengono quindi passate anch'esse alla workstation.

Se un utente membro di un gruppo universale, il SID di tale gruppo verr incluso nel token di accesso della workstation e quindi aggiunto ai dati relativi all'autorizzazione nel TGT emesso dal KDC.

I gruppi universali non vengono aggiunti ai token di accesso in nessun'altra fase, ad esempio al momento della creazione di token di rappresentazione presso i server membri. Di conseguenza, se il SID del gruppo universale non disponibile al momento della connessione dell'utente, ad esempio quando l'utente si connette a un dominio in modalit mista, non verr aggiunto nemmeno in un secondo tempo.

Nidificazione dei gruppi

consigliabile evitare di creare gruppi con pi di 5000 membri. Questa indicazione viene fornita sulla base della necessit di eseguire gli aggiornamenti dell'archivio di Active Directory in un'unica transazione. Poich le appartenenze ai gruppi vengono memorizzate in un unico attributo con pi valori, una modifica apportata a un'appartenenza comporta l'aggiornamento dell'intero attributo (ovvero dell'intero elenco delle appartenenze) in un'unica transazione. Microsoft ha testato e supporta al massimo 5000 membri nello stesso gruppo.

Per aggirare questa limitazione, possibile nidificare i gruppi in modo da aumentare il numero effettivo dei membri. Questa operazione consente inoltre di ridurre il traffico causato dalla replica delle modifiche apportate alle appartenenze ai gruppi.

Le opzioni di nidificazione disponibili variano a seconda del fatto che il dominio sia in modalit mista o nativa. Nell'elenco che segue viene descritto il contenuto di un gruppo residente in un dominio in modalit nativa. Le regole vengono determinate in base all'ambito di validit del gruppo stesso.

I gruppi universali possono includere account utente, account di computer, altri gruppi universali e gruppi globali appartenenti a qualsiasi dominio.

I gruppi globali possono includere account utente dello stesso dominio e altri gruppi globali appartenenti allo stesso dominio.

I gruppi locali al dominio possono includere account utente, gruppi universali e gruppi globali appartenenti a qualsiasi dominio, nonch altri gruppi locali al dominio appartenenti allo stesso dominio.

I gruppi di protezione di un dominio in modalit mista possono includere solo i seguenti elementi:

I gruppi locali possono includere gruppi globali e account utente appartenenti a domini trusted.

I gruppi globali possono includere solo account utente.

Effetti dell'aggiornamento sui gruppi

L'aggiornamento di un PDC a Windows 2000 non produce effetti immediati sui gruppi: i gruppi locali di Windows NT diventano gruppi locali di Windows 2000 e i gruppi globali di Windows NT diventano gruppi globali di Windows 2000. Il cambiamento effettivo si verifica quando il dominio passa alla modalit nativa, operazione in seguito alla quale i gruppi locali del PDC diventano gruppi locali al dominio.

Come precedentemente indicato, quando un utente viene autenticato viene creato un token di accesso contenente il SID principale e i SID di altri eventuali gruppi a cui l'utente appartiene. stato sottolineato che i gruppi locali del PDC rappresentano un caso a parte in Windows NT. Questo si riflette sull'aspetto del token di accesso di un utente membro di tale gruppo al momento della sua creazione nella workstation dell'utente in seguito alla connessione interattiva o presso un DC al fine di rappresentare l'utente per consentirgli l'accesso alle risorse. Poich i gruppi locali del PDC non hanno validit al di fuori del PDC e dei BDC del dominio, il token di accesso dell'utente nella workstation non contiene il SID del gruppo in questione. Quando l'utente cerca di accedere alle risorse di un DC, tuttavia, il token di rappresentazione creato per l'utente nel DC non contiene i SID di nessuno dei gruppi locali del PDC di cui l'utente membro.

Quando il dominio passa alla modalit nativa, poich i gruppi locali al dominio hanno validit solo all'interno del dominio, i SID dei gruppi locali al dominio di cui l'utente membro vengono aggiunti al rispettivo token di accesso anche se l'utente si connette in modo interattivo a una workstation.

Tabella 4. Gruppi e modalit del dominio

Tipo di gruppoAppartenenzaAmbito di validitDisponibile in modalit mista?

LocaleMembri provenienti da:

Stesso insieme di strutture

Altri insiemi di strutture trusted

Domini trusted di basso livelloComputerS

GlobaleMembri provenienti dal dominio localeQualsiasi dominio trustedS

Locale al dominioMembri provenienti da:

Stesso insieme di strutture

Altri insiemi di strutture trusted

Domini trusted di basso livelloIl dominio localeNo

UniversaleMembri provenienti dallo stesso insieme di strutture -forestaQualsiasi dominio trusted in modalit nativaNo

NetBIOS e WINS (Windows Internet Name Service) in Windows 2000

NetBIOS un'interfaccia di programmazione di rete di alto livello utilizzata dai componenti di rete Microsoft a partire dalla fine degli anni '80. Nello spazio dei nomi NetBIOS le risorse di rete vengono identificate da nomi NetBIOS univoci. WINS un servizio disponibile in Windows NT Server che supporta la registrazione di mapping dinamici dei nomi NetBIOS in indirizzi IP ed preposto alla risoluzione dei nomi NetBIOS.

In Windows 2000, il supporto dell'interfaccia dei nomi NetBIOS non pi necessario per i computer di rete e questo fatto, associato alla stretta collaborazione tra Active Directory e DNS (Domain Naming System), col passare del tempo sar causa del declino di NetBIOS. Attualmente, l'aggiornamento di un dominio a Windows 2000 non preclude la necessit del supporto di NetBIOS nella rete n influisce sul livello di supporto di cui si dispone.

Dopo aver eseguito l'aggiornamento, possibile abbandonare l'utilizzo di NetBIOS e WINS se si verificano le seguenti condizioni:

NetBIOS non viene utilizzato da nessun client come Windows per Workgroup, Windows 9x o Windows NT 4.0, e da nessun server in cui in esecuzione Windows NT 4.0. possibile che i nomi NetBIOS vengano ancora richiesti dalla rete per fornire servizi di base di file e stampa e il supporto di numerose applicazioni legacy eseguite in computer client con versioni precedenti dei sistemi operativi Windows.

Nell'ambito del processo di testing necessario valutare l'impatto delle applicazioni e dei servizi legacy. Si utilizza una rete di computer in cui viene eseguito esclusivamente Windows 2000 e si certi che tutti i computer e le applicazioni della rete siano in grado di funzionare utilizzando un altro servizio di naming come DNS. Il servizio di naming (risoluzione dei nomi) un indispensabile per l'individuazione di computer e risorse all'interno della rete, anche se non sono richiesti i nomi NetBIOS.

Il client WINS di Windows 2000 memorizza nella cache i nomi risolti localmente e utilizza un componente denominato Caching Resolver per eseguire ricerche nella cache prima di inviare una query al servizio DNS. Il file host viene memorizzato nella cache all'avvio del client e tutte le modifiche apportate a tale file vengono riportate immediatamente nella cache. Di seguito indicata la sequenza di risoluzione dei nomi:

1. Tentativo di risoluzione dei nomi nella cache del client.

2. Se il tentativo fallisce, il client prova a eseguire la risoluzione dei nomi mediante DNS.

3. Se anche la risoluzione dei nomi DNS ha esito negativo, il client prova a eseguire la risoluzione dei nomi mediante WINS.

Di conseguenza, se al momento dell'aggiornamento dei nuovi client sono state implementate funzioni di controllo delle modifiche sufficienti e sono state eliminate tutte le condizioni relative alle applicazioni legacy, il passaggio da NetBIOS e WINS dovrebbe avvenire senza problemi.

Disponibilit del servizio LMRepl (LAN Manager Replication)

In WindowsNTServer disponibile una funzione di replica denominata LMRepl (LAN Manager Replication), che spesso viene utilizzata per replicare gli script di accesso da un DC di esportazione a pi DC di importazione all'interno del dominio. In Windows2000 Server questo servizio viene sostituito dal servizio FRS (File Replication Service).

Poich Windows2000 Server non supporta LMRepl in modalit mista o nativa, se in passato si utilizzava tale servizio, necessario includere nel piano di aggiornamento una strategia per ottenere la stessa funzionalit mediante il servizio FRS.

Il processo LMRepl

Il servizio LMRepl si fonda su directory di importazione e di esportazione. Un amministratore pu configurare LMRepl selezionando un server in cui ospitare una directory di esportazione e pi server in cui includere le directory di importazione. Non necessario che i server in cui risiedono le directory siano DC, ma sufficiente che si tratti di normali server membri.

Figura 4. Il processo LMRepl

Il processo FRS

Il servizio FRS (File Replication Service) in Windows2000Server viene configurato automaticamente in modo che in ogni controller di dominio sia disponibile un volume di sistema (SYSVOL) replicato. Tutte le modifiche apportate a qualsiasi script di accesso memorizzato nel SYSVOL di qualsiasi controller di dominio verranno replicate in modalit multimaster negli altri controller di dominio. A differenza di LMRepl, che prevede directory di importazione ed esportazione, in FRS il volume SYSVOL pu essere incluso solo nei controller di dominio.

Figura 5. Il processo FRS

Gestione dei servizi LMRepl in ambiente misto

Come precedentemente indicato, durante l'aggiornamento si pu avere un ambiente misto con BDC di WindowsNT4.0 e server in cui sono installati controller di dominio di Windows2000. Poich Windows2000 Server non supporta il servizio LMRepl, mantenere tale servizio in un ambiente misto pu comportare dei problemi. Per ottenere questo supporto necessario creare una connessione tra LMRepl e FRS in modo da consentire il funzionamento di entrambi i servizi. Per farlo, necessario selezionare un DC di Windows 2000 di cui possibile utilizzare il volume SYSVOL per inserire dati nella directory di esportazione del BDC di Windows NT in cui risiede LMRepl. disponibile uno script di esempio Microsoft che possibile programmare per l'esecuzione delle operazioni di copia dei file necessarie.

Il servizio LMRepl e l'aggiornamento

Per mantenere la disponibilit del servizio LMRepl durante l'aggiornamento, necessario assicurarsi che il server in cui risiede la directory di esportazione venga aggiornato successivamente a tutti gli altri server in cui risiedono le directory di importazione. Se il server con la directory di esportazione il PDC, necessario selezionare un nuovo server di importazione e quindi riconfigurare il servizio LMRepl.

Utilizzo di servizi RAS (Remote Access Services) in ambiente misto

Se si utilizzano servizi RAS per fornire agli utenti l'accesso remoto alla rete aziendale, pu essere necessario aggiornare il server RAS all'inizio del processo di aggiornamento dei server membri. Per questo motivo Windows NT verifica le propriet RAS come la disponibilit dell'accesso ai servizi RAS o le richiamate per gli utenti.

RAS un esempio di servizio di Windows NT. Un servizio un tipo di processo eseguito in background, studiato per essere eseguito continuamente senza interfaccia utente e in genere preposto all'esecuzione di funzioni server quali, ad esempio, quelle di un server Web o FTP. Dovendo funzionare anche quando nessun utente connesso al sistema, il servizio viene eseguito nel contesto di protezione di uno speciale account di servizio, in genere l'account di sistema, noto anche come LocalSystem.

L'account di sistema un particolare account noto solo al computer locale a cui vengono concessi tutti i privilegi disponibili nel sistema operativo. Quando un servizio si connette come LocalSystem, presenta credenziali NULL, ovvero, in altri termini, non fornisce nome utente o password. Ci significa che tale account non pu essere utilizzato per accedere a risorse di rete basate sull'autenticazione NTLM, a meno che il computer locale non consenta l'accesso con credenziali NULL (a cui spesso viene fatto riferimento come sessione NULL). In Windows NT, il servizio RAS utilizza l'account LocalSystem.Per impostazione predefinita, poich Active Directory non accetta la ricerca di attributi di un oggetto eseguita in sessioni NULL, in un ambiente misto un server RAS di Windows NT non in grado di recuperare le propriet RAS di un utente se non vengono soddisfatte le seguenti condizioni:

Il dominio in modalit mista e il server RAS di Windows NT anche un BDC. In questo caso, il servizio RAS avr accesso locale al SAM.

Il dominio in modalit mista e il server RAS di Windows NT contatta un BDC di Windows NT, con un comportamento identico a quello attuale di Windows NT. Questo pu comportare alcune discrepanze.

Il dominio in modalit mista o nativa e la protezione di Active Directory stata allentata per concedere all'entit predefinita Everyone le autorizzazioni di lettura di qualsiasi propriet o oggetto dell'utente. L'installazione guidata di Active Directory (DCPROMO) consente all'utente di selezionare questa configurazione grazie all'opzione di riduzione delle autorizzazioni disponibile in alcuni oggetti di Active Directory.

Questa procedura deve essere adottata come soluzione estrema e solo dopo averne studiato attentamente l'impatto sulla protezione di Active Directory. Se si ritiene che possano crearsi conflitti con i requisiti di protezione stabiliti, necessario adottare il metodo consigliato, che prevede l'aggiornamento del server RAS di Windows NT a Windows 2000 che quindi diventer membro di un dominio in modalit mista o nativa di Windows 2000. In questo modo inoltre possibile evitare discrepanze di comportamento mentre il dominio in modalit mista, come descritto nella seconda condizione.

Nel piano di aggiornamento necessario considerare questi fattori, tenendo presente l'opportunit di aggiornare il server RAS nella fase iniziale del processo.

Percorsi di aggiornamento supportati

In fase di pianificazione dell'aggiornamento a Windows 2000 importante considerare i sistemi operativi gi distribuiti nell'azienda e la possibilit di aggiornarli direttamente a Windows 2000.

Nella Tabella 5, riportata di seguito, viene presentato l'elenco dei percorsi di aggiornamento supportati per Windows 2000. Nei casi in cui necessario provvedere all'aggiornamento, ma non sia possibile eseguirlo direttamente, il processo verr eseguito mediante un diverso sistema operativo, ad esempio Windows 9x, Windows NT 3.51/4.0 Workstation o Windows NT 3.51/4.0 Server. Questa operazione deve essere rispecchiata nel piano di aggiornamento.

Tabella 5. Percorsi di aggiornamento supportati

PiattaformaAggiornamento a Windows2000 ProfessionalAggiornamento a Windows2000 Server

Windows 3.xNoNo

Windows NT 3.1 NoNo

Windows NT 3.1 Advanced ServerNoNo

Windows NT 3.51 WorkstationSNo

Windows NT 3.51 ServerNoS

Windows 9xSNo

Windows NT 4.0 WorkstationSNo

Windows NT 4.0 ServerNoS

Ordine di aggiornamento dei domini

Fino a questo punto stato descritto l'ordine di aggiornamento dei DC di un dominio. Questo argomento non lascia spazio a molte divagazioni: infatti necessario aggiornare prima il PDC e quindi i BDC. La questione pi problematica quale dominio aggiornare per primo in quanto la risposta pu variare a seconda delle circostanze. Ad esempio, se si intende ristrutturare determinati domini che ancora non esistono, non ha molta importanza che vengano aggiornati per primi.

Nonostante la variet delle situazioni possibili, in linea di massima consigliabile attenersi al seguente ordine di aggiornamento dei domini:

1. Domini di account

2. Domini di risorse

Aggiornamento dei domini di account

In generale pi vantaggioso aggiornare per primi i domini di account in quanto nella maggior parte dei casi necessario amministrare pi utenti che computer. L'aggiornamento dei domini di account a Windows 2000 presenta i seguenti vantaggi:

Migliore scalabilit di Active Directory. In molte organizzazioni il numero di utenti e gruppi supera le dimensioni consigliate per il SAM.

Amministrazione delegata. possibile delegare le funzioni amministrative in maniera capillare senza dover concedere il potere assoluto.Ordine dei domini di account

Se sono presenti pi domini di account, possibile decidere in quale ordine verranno aggiornati seguendo le indicazioni riportate di seguito:

Massimo controllo. Anche se la strategia di migrazione stata testata a livello teorico o mediante esperimenti pilota, la prima migrazione effettiva sar la pi rischiosa. Per mitigare il rischio, possibile aggiornare i domini nei punti in cui si ha pi facile accesso ai DC. Riduzione dei rischi e dei disagi. Se in qualsiasi situazione sono presenti pi domini da aggiornare, consigliabile iniziare da quello di dimensioni inferiori in modo da ridurre al minimo i disagi arrecati agli utenti, in particolare mentre si acquisisce familiarit con il processo. Un lavoro ben fatto. Una volta acquisita familiarit con il processo, possibile passare ai domini di account pi grandi.

Destinazioni della ristrutturazione del dominio di account. Se si intende ristrutturare i domini, consigliabile provvedere ad aggiornare le probabili destinazioni della ristrutturazione all'inizio del processo. Infatti, non possibile consolidare domini in una destinazione che non esiste.

Ordine dei domini di risorse

Se sono presenti pi domini di risorse, possibile decidere in che ordine verranno aggiornati seguendo le indicazioni riportate di seguito:

Funzioni necessarie per le applicazioni. innanzitutto necessario ristrutturare i domini in cui verranno distribuite applicazioni che richiedono l'infrastruttura o le funzioni di Windows 2000, ad esempio Active Directory per Microsoft Exchange 2000 (nome in codice Platinum, la prossima versione di Microsoft Exchange).

Domini con pi workstation. A questo punto, possibile passare all'aggiornamento dei domini con molte workstation in modo da avvalersi degli elementi infrastrutturali di Windows 2000, ad esempio Microsoft IntelliMirror(.

Destinazioni della ristrutturazione del dominio di risorse. Come per i domini di account, se si intende ristrutturare i domini di risorse, consigliabile provvedere ad aggiornare le probabili destinazioni della ristrutturazione all'inizio del processo.

Aggiornamento di workstation e server

Anche se il principale obiettivo di questo documento illustrare il processo di aggiornamento e consolidamento dei domini, ci non significa che la distribuzione delle workstation e dei server membri di Windows2000 debba essere rimandata fino all'avvenuto aggiornamento dell'infrastruttura dei domini. Infatti, l'utilizzo di workstation e server Windows2000 in un ambiente Windows NT esistente offre comunque una serie di vantaggi. Nella tabella che segue vengono indicati alcuni dei vantaggi derivanti dal semplice aggiornamento di workstation e server a Windows2000.

Tabella 6. Vantaggi dell'aggiornamento di workstation o server

VantaggioFunzioni

Gestibilit Plug and Play

Installazione guidata hardware con Gestione periferica

Supporto di USB (Universal Serial Bus)

MMC (Microsoft Management Console)

Nuova utilit di backup

Supporto del file system Le nuove funzioni di NTFS 5.0 includono il supporto per le quote disco, la possibilit di deframmentare le strutture di directory e l'I/O di rete compresso

FAT32

Servizi per le applicazioni Microsoft Win32 Driver Model

Microsoft DirectX 5.0

Windows Scripting Host

Pubblicazione e condivisione delle informazioni Microsoft Distributed File System (DFS) per Windows NT Server un componente server di rete che semplifica le operazioni di ricerca e gestione dei dati nella rete eseguite dagli utenti.

Shell Internet integrata

Scalabilit e disponibilit Migliore supporto per piattaforme multiprocessori simmetriche - SMP

Ristrutturazione dei domini

L'aggiornamento dei domini un processo volto a preservare per quanto possibile l'ambiente esistente, compresa la struttura dei domini, mentre la ristrutturazione dei domini un processo che permette di reimpostare l'insieme di strutture in base alle esigenze della propria organizzazione. Anche se la ristrutturazione pu produrre innumerevoli risultati diversi, in genere consente la razionalizzazione della struttura corrente e talvolta il passaggio a un minor numero di domini di maggiori dimensioni.

In passato, il supporto alla ristrutturazione dei domini di Windows NT veniva fornito da numerosi strumenti di terze parti per la gestione delle directory. Oggi, per la prima volta, in Windows 2000 disponibile una funzionalit nativa che supporta diverse situazioni di ristrutturazione dei domini, in particolare:

Possibilit di spostare i criteri di protezione tra domini pur mantenendo invariate le caratteristiche di accesso alle risorse.

Possibilit di spostare i DC tra domini senza dover reinstallare completamente il sistema operativo.

Microsoft sta per distribuire uno strumento grafico per semplificare il processo di ristrutturazione dei domini, nonch alcuni componenti COM che supportano gli script e utilit della riga di comando a sostegno delle operazioni di ristrutturazione. Questi strumenti risulteranno particolarmente utili per molti clienti che intendono implementare gli scenari descritti di seguito. Per i clienti che richiedono strumenti grafici pi sofisticati, Microsoft sta collaborando con diversi ISV (Independent Software Vendor) per creare un mercato altrettanto ricco di strumenti di terze parti corredati da un maggior numero di funzioni.

Quando eseguire la ristrutturazione

opportuno provvedere alla ristrutturazione in tre gruppi di situazioni:

Successivamente all'aggiornamento. Per la maggior parte delle organizzazioni il momento migliore per eseguire la ristrutturazione dei domini coincide con la seconda fase della migrazione a Windows 2000, al termine di un precedente aggiornamento.

In seguito all'aggiornamento saranno stati adeguati i casi pi semplici, ad esempio gruppi di domini in cui la struttura del trust essenzialmente corretta e casi in cui non esistono implicazioni di carattere amministrativo.

In queste situazioni, probabilmente, la ristrutturazione volta a reimpostare altre parti della struttura dei domini in modo da ridurne il grado di complessit oppure a inserire in modo sicuro nell'insieme di strutture domini di risorse con amministratori non trusted.

In sostituzione dell'aggiornamento. I responsabili di alcune organizzazioni possono ritenere, per svariati motivi, che la struttura corrente dei domini sia irrecuperabile o che l'organizzazione non possa permettersi di compromettere la stabilit dell'ambiente di produzione corrente durante la migrazione. In questi casi, il percorso di migrazione pi semplice prevede la progettazione e la creazione di un ambiente Windows 2000 puro, separato dall'ambiente di produzione. In questo caso, con il passare del tempo il nuovo insieme di strutture Windows 2000 destinato a sostituirsi all'ambiente di produzione stesso.

Dopo aver creato il nuovo insieme di strutture, la ristrutturazione ha inizio con un'operazione pilota nell'ambito della quale numerosi utenti, gruppi e risorse vengono fatti migrare nel nuovo ambiente a titolo sperimentale, per garantire il normale svolgimento delle attivit nella nuova struttura.

Una volta completata questa fase, l'operazione pilota prosegue con una migrazione graduale al nuovo ambiente. A un certo punto del processo, Windows 2000 si sostituisce all'ambiente di produzione. La vecchia struttura di domini viene disabilitata e le rimanenti risorse ridistribuite.

Successivamente alla migrazione. In questo caso, la ristrutturazione avviene nell'ambito di un rinnovamento generale all'interno di un ambiente costituito interamente da computer in cui installato Windows 2000. Questo processo pu richiedere diversi anni se, per qualsiasi motivo (ad esempio un cambiamento dell'organizzazione o l'acquisizione di nuove societ) la struttura corrente diventa inadeguata.In questo capitolo verr presa in esame principalmente la migrazione iniziale da Windows NT 4.0 a Windows 2000, e in particolare in relazione ai primi due casi. Alcuni dei metodi descritti di seguito possono risultare utili anche nel terzo caso, anche se gi prevista l'elaborazione di strumenti e tecniche pi completi successivamente alla prima release.

Figura 6. Quando eseguire la ristrutturazione

Perch eseguire la ristrutturazione

La ristrutturazione pu rendersi necessaria per svariati motivi, di cui il principale rappresentato dalla possibilit di avvalersi delle funzioni di Windows 2000 che permettono di strutturare in maniera ottimale i propri domini in base alle esigenze dell'organizzazione. Ad esempio:

Maggiore scalabilit. possibile che la precedente struttura di domini di Windows NT sia stata progettata rispettando le limitazioni dimensionali dei database di account SAM e che pertanto sia stato necessario implementare un modello a uno o pi domini master. Grazie alla scalabilit notevolmente migliorata di Active Directory, che consente di includere milioni di account utente o gruppi, possibile ristrutturare i domini Windows NT correnti creando un minor numero di domini Windows 2000 di dimensioni maggiori.

Amministrazione pi capillare. possibile che nel modello corrente siano stati implementati domini di risorse per consentire la delega di responsabilit amministrative. Poich le OU di Windows 2000 possono includere qualsiasi tipo di criteri di protezione, possibile delegare l'amministrazione nel modo appropriato. In molti casi, la conversione dei domini di risorse in OU rappresenta il metodo pi appropriato per delegare le funzioni amministrative.

Amministrazione semplificata. La struttura di domini pu essere collegata a una combinazione complessa di trust per consentire la delega delle attivit amministrative in base alle modalit sopra descritte o conseguentemente all'acquisizione di societ. possibile implementare alcuni domini , semplificando cos le funzioni amministrative. In alternativa, possibile reimpostare la struttura di domini avvalendosi di un minor numero di trust transitori bidirezionali.

Le situazioni che verranno descritte di seguito non richiedono il completamento della fase iniziale dell'aggiornamento.

Implicazioni della ristrutturazione dei domini

Come precedentemente indicato, i principali incentivi alla ristrutturazione sono rappresentati dalla possibilit di spostare i criteri di protezione e i DC tra domini. In questa sezione verranno prese in esame le implicazioni di tali funzioni e il loro effetto sulla pianificazione della ristrutturazione.

Effetti dello spostamento dei criteri di protezione nei SID

Poich i SID sono correlati ai domini, quando si sposta tra domini un criterio di protezione come un utente o un gruppo, necessario assegnarvi un nuovo SID per il nuovo dominio.

Come illustrato nella sezione sull'aggiornamento, nel modello di protezione di Windows NT il sistema operativo assegna l'accesso alle risorse in base al token di accesso dell'utente, e confrontando il SID principale dell'utente e i SID dei gruppi di cui membro con l'ACL incluso nel descrittore di protezione delle risorse in questione. Gli ACL sono elenchi di SID che indicano se l'accesso alle risorse viene concesso o negato ai criteri di protezione identificati dal SID. Pertanto, la modifica del SID comporta importanti implicazioni.

Di seguito riportato un esempio che illustra tali implicazioni in base alle nozioni sulla protezione in Windows NT. L'utente Luca, un dipendente della ditta Hay Buv Toys, dispone di un account nel dominio master di Windows NT 4.0 HAYBUV-ACCT. Luca membro del gruppo globale Analisti finanziari appartenente allo stesso dominio.

Hay Buv Toys utilizza un'applicazione finanziaria Win32 in esecuzione in diversi computer Windows NT Server nel dominio di risorse HAYBUV-RIS1. Per avvalersi della condivisione dei gruppi locali creati nel PDC tra tutti i DC del dominio, i server in cui viene eseguita l'applicazione fungono da BDC del dominio. Il gruppo locale condiviso Risorse finanziarie stato creato nel PDC e viene utilizzato negli ACL dei file in uso nell'applicazione. Il gruppo globale HAYBUV -ACCT\Analisti finanziari un membro di HAYBUV -RIS1\Risorse finanziarie.

Luca pu accedere anche a un file server, FIN_FILES1, nel dominio di risorse. FIN_FILES1 semplicemente un computer Windows NT Server in cui viene eseguito un server membro. FIN_FILES1 utilizza il gruppo locale File finanziari negli ACL dei file relativi al gruppo a cui appartiene Luca. HAYBUV -ACCT\Analisti finanziari un membro di FIN_FILES1\File finanziari. Luca lavora ad alcuni progetti privati in una directory di FIN_FILES1 protetta in modo che solo Luca possa accedere ai file che vi risiedono. Tale directory include un ACL costituito da una sola voce che consente a Luca il pieno controllo del suo contenuto.

Figura 7. Esempio di accesso alle risorse

Spostamento dei criteri di protezione

Come precedentemente indicato, lo spostamento di un criterio di protezione tra domini comporta la modifica del SID del criterio stesso.

Le implicazioni dello spostamento dei criteri di protezione risulta evidente se si considera cosa succederebbe se l'account di Luca venisse spostato in un altro dominio nell'ambito di un processo di migrazione che comporta la ristrutturazione dei domini.

Ai fini di questo esempio, si presuma che HAYBUV-ACCT sia stato aggiornato a Windows 2000 e aggiunto al nuovo insieme di strutture Windows 2000 della societ come dominio figlio del dominio principale HAYBUV.TLD. HAYBUV-ACCT passato in modalit nativa, ma deve essere ristrutturato e i suoi membri verranno trasferiti nel nuovo dominio Windows 2000 HAYBUV-ACCT2 in una diversa posizione nell'insieme di strutture.

Effetti dello spostamento sull'appartenenza dell'utente Luca al gruppo globale

HAYBUV-ACCT \Luca membro del gruppo globale HAYBUV-ACCT\Analisti finanziari. poich un gruppo globale pu includere solo membri appartenenti al proprio dominio, in seguito allo spostamento di Luca nel nuovo dominio il nuovo account non potr pi far parte del gruppo e, pertanto, Luca non potr pi accedere alle risorse disponibili per il gruppo stesso.

Presupponendo che il trust esistente tra il nuovo dominio e il dominio di risorse sia sufficiente, risulta evidente che il problema pu essere risolto in diversi modi:

Aggiungendo il nuovo SID di Luca agli ACL delle risorse. possibile mantenere l'accesso alle risorse aggiungendo il nuovo SID di Luca agli ACL di tutte le risorse a cui aveva accesso in qualit di membro del gruppo. Questa operazione richiederebbe molto tempo e sarebbe fonte di confusione per svariati motivi:

Molte operazioni relative alla ristrutturazione dei domini vengono eseguite gradualmente nell'arco di un periodo di transizione durante il quale non possibile garantire che non verranno create nuove risorse per il gruppo Analisti finanziari. Questo comporterebbe il rinnovamento costante delle autorizzazioni durante i periodi di coesistenza dei due gruppi nell'ambito del processo di migrazione.

Microsoft consiglia di utilizzare gruppi e non singoli utenti all'interno degli ACL. Infatti, l'appartenenza a gruppi che svolgono mansioni professionali specifiche pu variare nel tempo ed pi facile rimuovere un utente da un gruppo che non modificare gli ACL di numerose risorse che fanno riferimento a tale utente. A questo punto bisogna chiedersi cosa succederebbe se cambiasse la mansione professionale di Luca e se, pertanto, la sua appartenenza al gruppo Analisti finanziari non avesse pi ragione di essere.

Spostando il gruppo. Allo stesso modo in cui possibile spostare i criteri di protezione in Windows 2000, il gruppo stesso pu essere spostato in un nuovo dominio. Tuttavia, poich gli ACL riferiti a un gruppo fanno riferimento anche al relativo SID, la stessa operazione dovrebbe essere eseguita anche nel primo caso, ovvero, in altri termini, sarebbe necessario rinnovare le autorizzazioni di accesso alle risorse facendo riferimento al nuovo SID.

Creando un gruppo parallelo nel dominio di destinazione. Se fosse necessario spostare un gruppo e non fosse previsto lo spostamento di tutti i suoi membri in una sola transazione, sorgerebbe un problema. Ci significa che sarebbe necessario mantenere il gruppo nel vecchio dominio e creare un gruppo parallelo nel nuovo dominio. Verrebbe mantenuto l'accesso alle risorse del gruppo originale e i relativi membri, ma sarebbe necessario rinnovare le autorizzazioni in modo da consentire al nuovo gruppo di accedere alle risorse. Anche in questo caso, le autorizzazioni dovrebbero essere rinnovate continuamente fintanto che il gruppo esiste in entrambi i domini.

Effetti dello spostamento all'interno degli ACL che fanno riferimento diretto all'utente Luca

Luca pu accedere direttamente anche ad alcune risorse residenti nel server membro FIN_FILES. Il suo SID compare negli ACL di tale computer.

Aggiungere utenti agli ACL delle risorse perfettamente lecito, ma lo spostamento di Luca a prima vista sembra comportare la necessit di rinnovare le risorse residenti nel server aggiungendo il SID del nuovo dominio.

Da sempre Microsoft consiglia di utilizzare gruppi e non singoli utenti negli ACL delle risorse. In molte organizzazioni, tuttavia, possibile che questo non avvenga e che pertanto sia necessario ricercare e aggiornare tutti i riferimenti all'utente spostato in tutti gli ACL delle risorse dell'intera organizzazione.

SIDhistory

In molti casi le operazioni precedentemente descritte non sono pi necessarie grazie al nuovo attributo delle directory di Windows 2000 denominato SIDhistory.

SIDhistory un attributo dei criteri di protezione di Active Directory utilizzato per memorizzare i precedenti SID di oggetti spostati, ad esempio utenti e gruppi di protezione.

Se un utente o un gruppo viene spostato utilizzando le nuove API di Win32 o le utilit di base fornite da Microsoft e incorporate nelle API, l'attributo SIDhistory dell'oggetto che lo rappresenta in Active Directory viene aggiornato con il SID precedente durante l'operazione. Quando l'utente si connette al sistema, oltre alle appartenenze dell'utente al gruppo il sistema recupera le voci dell'attributo SIDhistory dell'utente e le aggiunge al relativo token di accesso.

Essendo possibile spostare i gruppi, il sistema recupera anche gli attributi SIDhistory di tutti i gruppi di cui l'utente membro e li aggiunge al token di accesso dell'utente. Al momento della verifica delle autorizzazioni, il sistema considera le voci dell'attributo SIDhistory aggiunte al token come normali appartenenze a gruppi, idonee a garantire l'accesso anche in sistemi di basso livello che non riconoscono Windows 2000 o Active Directory.

Figura 8. Accesso alle risorse consentito da SIDhistory

Spostamento di utenti e gruppi durante l'aggiornamento di SIDhistory eseguito utilizzando MoveTree.exe

MoveTree il nome di un'utilit di base per la migrazione dei domini disponibile in Windows 2000.Tale utilit consente lo spostamento di oggetti delle directory, inclusi i criteri di protezione, tra domini Windows 2000 appartenenti allo stesso insieme di strutture. L'utilit consente inoltre di aggiornare l'attributo SIDhistory degli utenti o dei gruppi spostati. MoveTree permette di spostare oggetti quali OU, gruppi e account utente o di computer.

Limitazioni all'utilizzo di MoveTree

Sono previste alcune limitazioni all'utilizzo di MoveTree. Questa utilit richiede:

Dominio di origine in modalit mista o nativa. Il dominio da cui l'oggetto viene spostato (origine) deve essere un dominio Windows 2000 in modalit mista o nativa.

Dominio di destinazione in modalit nativa. Il dominio in cui l'oggetto viene spostato (destinazione) deve essere un dominio Windows 2000 in modalit nativa.

Domini di origine e di destinazione. Devono appartenere allo stesso insieme di strutture.

Gruppi globali vuoti. MoveTree permette di spostare le OU e il relativo contenuto e, in un dominio di origine in modalit nativa, i gruppi universali e il relativo contenuto. MoveTree, tuttavia, consente di spostare solo gruppi globali vuoti. Attualmente per utilizzare MoveTree, prima di spostare i gruppi globali necessario svuotarli del loro contenuto, che quindi verr reinserito una volta giunti a destinazione.

Set chiusi. Gli oggetti devono essere spostati in set chiusi. Il significato di questo termine varia a seconda che sia riferito allo spostamento di utenti e gruppi globali oppure allo spostamento di computer (che potrebbero utilizzare gruppi locali condivisi, come nel caso dei DC di Windows NT) o di gruppi locali al dominio (ad esempio DC di Windows 2000, server e workstation in un dominio in modalit nativa).

Set chiusi e spostamento di utenti e gruppi globali

Come precedentemente indicato, un gruppo globale pu includere solo membri appartenenti allo stesso dominio. Per mantenere l'accesso alle risorse protette da ACL che fanno riferimento a gruppi globali, quando un utente viene spostato tra domini necessario spostare anche i gruppi globali a cui appartiene. Analogamente, se viene spostato un gruppo globale necessario spostare anche i relativi membri.

In questo caso, un set chiuso di utenti e gruppi globali un set in cui per ogni utente spostato necessario spostare anche i gruppi globali di cui membro e per ogni gruppo globale necessario spostare anche i relativi membri.

Se il dominio di origine in modalit nativa, i gruppi globali possono includere anche altri gruppi globali. In caso di spostamento di un gruppo nidificato, necessario spostare anche tutti i suoi membri e tutti i gruppi globali a cui tali membri appartengono.

Set chiusi e spostamento di computer

I gruppi locali condivisi e i gruppi locali al dominio sono validi solo all'interno del dominio in cui sono stati creati. Se un gruppo di questo tipo viene spostato, tutti i riferimenti al gruppo stesso negli ACL del dominio di origine non possono essere risolti.

In questo caso, un set chiuso di computer e di gruppi condivisi o locali al dominio un set in cui per ciascun gruppo spostato necessario spostare anche tutti i computer del dominio contenenti ACL che fanno riferimento al gruppo stesso. Inoltre, per ciascun computer spostato necessario spostare tutti i gruppi condivisi o locali al dominio a cui fanno riferimento gli ACL delle relative risorse.

Problemi relativi ai set chiusi

Le limitazioni allo spostamento di gruppi locali e set chiusi sono particolarmente onerose. Lo svuotamento e il reinserimento dei membri di gruppi globali di grandi dimensioni pu richiedere molto tempo e in alcuni casi il set chiuso minore rappresentato dall'intero dominio di origine.

In questi casi possibile risolvere il problema procedendo in tre diversi modi:

Gruppi paralleli. Per ciascun gruppo da spostare possibile creare un gruppo globale parallelo nel dominio di destinazione e quindi individuare tutte le risorse dell'azienda contenenti ACL che fanno riferimento al gruppo originale, rinnovando le autorizzazioni in modo da includervi il riferimento al gruppo parallelo.

Questa operazione pu risultare particolarmente onerosa quando necessario spostare gruppi globali, che necessitano di riferimenti nelle risorse di qualsiasi dominio trusting, oppure spostare gruppi locali al dominio da domini in modalit nativa in cui i gruppi locali al dominio possono essere utilizzati in qualsiasi computer del dominio stesso.

Gruppi universali. possibile far passare il dominio alla modalit nativa e quindi convertire i gruppi da spostare in gruppi universali. Poich i gruppi universali hanno validit nell'intero insieme di strutture, in seguito alla conversione possibile spostare i gruppi senza problemi mantenendo l'accesso alle risorse.

Questo metodo deve essere adottato con estrema cautela in quanto, come precedentemente indicato, l'appartenenza ai gruppi universali viene memorizzata nel GC e questo influisce sul traffico di replica del GC.

Per questo motivo pu essere necessario adottare questo metodo come strategia di transizione durante la migrazione di utenti e gruppi nel nuovo dominio. Quindi, una volta completato il processo di migrazione, possibile ripristinare il tipo originale dei gruppi.

Clonazione. possibile clonare i gruppi del dominio di origine nel dominio di destinazione, mantenendo l'attributo SIDhistory. Questa tecnica presenta limitazioni specifiche, illustrate nella sezione Clonazione dei criteri di protezione.

Clonazione dei criteri di protezione

Fino a questo momento la ristrutturazione stata considerata come un processo attivato dallo spostamento dei criteri di protezione. In un certo senso, questa pu essere ritenuta un'operazione distruttiva in quanto spostando i criteri di protezione si esclude la possibilit di tornare all'account precedente in caso di problemi durante la migrazione.

Molti clienti hanno manifestato l'esigenza di poter eseguire gradualmente la migrazione degli utenti a un nuovo dominio Windows 2000, mantenendone i vecchi account nel dominio di origine, per garantirsi una possibilit di recupero in caso di eventuali errori irreversibili durante la migrazione pilota o di massa. Microsoft ha attivato questa funzionalit, denominata clonazione, per Windows 2000. Microsoft fornisce le utilit di base ClonePrincipal, che permettono di clonare un utente o un gruppo da un dominio di origine Windows NT 4.0 o Windows 2000 a un dominio Windows 2000 in modalit nativa senza dover rimuovere l'account di origine. Al tempo stesso, questa utilit permette di aggiungere il SID dell'account originale all'attributo SIDhistory del nuovo account per mantenere l'accesso alle risorse.

ClonePrincipal

L'utilit ClonePrincipal costituita da un componente che supporta gli script e che attiva la clonazione dei criteri di protezione e degli script di esempio che illustrano l'utilizzo del componente. Tali script possono essere personalizzati da amministratori in grado di utilizzare Microsoft Visual Basic( (VB).

Poich la clonazione un'operazione basata sulla protezione, sono previste alcune limitazioni all'utilizzo di ClonePrincipal:

I domini di origine e di destinazione non possono risiedere nello stesso insieme di strutture.

Il SID dell'account di origine non deve esistere nell'insieme di strutture di destinazione n come SID principale, n nell'attributo SIDhistory di nessun criterio di protezione.

Per eseguire ClonePrincipal l'utente deve disporre di privilegi di amministratore di dominio in entrambi i domini di origine e di destinazione.

Il controllo deve essere attivato nel dominio di destinazione e, preferibilmente, anche nel dominio di origine.

Definizione di trust

In situazioni di clonazione in cui i domini di origine e di destinazione risiedono in insiemi di strutture diversi, si dovr provvedere innanzitutto a stabilire i trust necessari per garantire l'accesso alle risorse.

Netdom.exe uno strumento disponibile nel Resource Kit di Windows 2000 Server che permette di eseguire operazioni come l'enumerazione dei trust di dominio e la definizione di nuovi trust.

Questo strumento consente inoltre di creare account di computer e aggiornare l'appartenenza ai domini di workstation o server.

Spostamento di server

Nell'esempio precedente, l'utente Luca pu accedere ad alcune risorse nel server membro FIN_FILES1, utilizzando gli A