Progettazione ottimale di Active Directory per la gestione delle reti

Progettazione ottimale di Active Directory per la
gestione delle reti Windows
Microsoft Windows 2000
Microsoft Corporation
Riconoscimenti
Si ringraziano le seguenti persone per aver revisionato le guide e per avere fornito commenti e consigli utili (se non
diversamente specificato, le persone indicate sono dipendenti di Microsoft Corporation):
Micky Balladelli (Avanade Inc.), Dung Hoang Khac (Compaq Global Services), Vic Gupta, Shaun Hayes, Michael Kostersitz,
Doug Lindsey, Alain Lissoir (Compaq Global Services), Tony Mosunmade, Tony Redmond (Compaq Global Services), Matthijs
ten Seldam, Paul Thompson (NetIQ Corporation), Ruud van Velsen, Eddie Hanif, Frank Plawetzki, Connie Shih, Steve Towle,
Christopher Westpoint.
Personale di laboratorio: Robert Thingwold e David Meyer
Partner di laboratorio: Compaq, Inc. e Cisco Systems.
Contenuti
Guida alla progettazione ottimale
Introduzione
Definizione del numero di foreste nell'organizzazione
Creazione dell'architettura dei domini
Creazione di una struttura DNS per Active Directory
Creazione dell'architettura delle unità organizzative
Creazione della topologia dei siti
Implementazione della progettazione
Fogli di lavoro relativi al numero di foreste dell'organizzazione
Fogli di lavoro per la progettazione delle foreste Active Directory
Guida alla progettazione ottimale
Un approccio strutturato alla progettazione di Active Directory facilita il deployment del servizio di directory su scala aziendale
e ne semplifica la comprensione. La presente guida, insieme a Best Practice Active Directory Deployment for Managing
Windows Networks, intende fornire indicazioni aziendali e tecniche per ridurre al minimo il tempo e l'impegno necessari per
implementare il servizio Active Directory™.
Nel presente documento viene delineata fase per fase la metodologia ottimale adottata dai clienti che hanno eseguito il
deployment del servizio Active Directory nelle proprie organizzazioni. Verranno illustrate tutte le attività e le decisioni
necessarie per sviluppare un'architettura Active Directory destinata alla gestione delle reti Windows. I destinatari della guida
sono i professionisti del settore IT responsabili delle attività di testing, di creazione dei progetti pilota e di implementazione
dell'architettura Active Directory.
Introduzione
Mediante il servizio Active Directory di Windows® 2000 le organizzazioni sono in grado di semplificare la gestione di utenti e
risorse e di creare al tempo stesso un'infrastruttura con caratteristiche di scalabilità, sicurezza e facilità di gestione per il
deployment di ulteriori tecnologie importanti e innovative.
Per abbreviare i tempi di pianificazione e per garantire una buona esecuzione dei deployment, Microsoft pubblica una serie di
guide basate su possibili scenari. Tali guide forniscono un aiuto per la realizzazione di progetti, basato sulle attività e orientato
alle soluzioni.
Progettazione ottimale di Active Directory per la gestione delle reti Windows e Best Practice Active Directory Deployment for
Managing Windows Networks fanno parte di questa serie. Queste guide offrono un approccio strutturato alla progettazione e
all'esecuzione del deployment di Active Directory. In mancanza di un approccio di questo tipo, l'implementazione di Active
Directory in azienda può richiedere più tempo del necessario.
Queste guide integrano l'esperienza dei team di prodotto Microsoft che si occupano della pianificazione e del deployment con le
esperienze dei clienti che hanno già progettato ed eseguito il deployment di Active Directory nelle proprie organizzazioni.
Scenari di deployment di Active Directory
Nel contesto di un'organizzazione, Active Directory può svolgere ruoli diversi, a differenza di quanto accade con le directory
destinate a finalità speciali. Si va dalla gestione delle reti Windows al supporto di applicazioni per l’e-commerce abilitate al
servizio di directory. Tuttavia, il modo in cui si intende utilizzare Active Directory influirà sulle decisioni di rilievo correlate alla
progettazione e all'esecuzione del deployment.
Active Directory per la gestione delle reti Windows
Questa guida descrive le metodologie ottimali per realizzare un deployment di Active Directory studiato allo scopo di
ottimizzare la gestione delle reti costituite da client e server Windows e da applicazioni e periferiche compatibili con Windows.
Nella guida, questo compito viene definito ruolo della gestione del sistema operativo di rete (NOS, Network Operating
System). I vantaggi derivanti dal deployment di Active Directory per chi ricopre il ruolo di gestione del NOS includono:
•
Gestione centralizzata di reti Windows di grandi dimensioni (Active Directory consente di supportare milioni di
oggetti).
•
•
•
•
•
Capacità di eliminare i domini di risorse e, quindi, l'hardware e le attività amministrative che essi comportano.
•
Nel presente documento viene preso in esame soltanto il deployment dei servizi essenziali di Active Directory e del
DNS nell'ambito della gestione di una rete Windows. È possibile aggiungere successivamente altri servizi che si
basano su Active Directory, senza che ciò abbia impatto sull'architettura iniziale. Ad esempio, i criteri di gruppo
possono semplificare la gestione grazie all'amministrazione di utenti, gruppi, workstation e server. Tra i servizi che si
basano su Active Directory vi sono:
•
•
•
•
Criteri di gruppo
Controllo dei desktop e distribuzione del software basati sui criteri di gruppo (Group Policy).
Capacità di delegare il controllo amministrativo delle risorse, in caso di necessità.
Organizzazione ed utilizzo semplificati delle risorse condivise.
Per ulteriori informazioni sul valore aziendale del deployment di Active Directory, visitare l'indirizzo:
www.microsoft.com/italy/windows2000/.
Exchange 2000
Servizi integrati con infrastruttura a chiave pubblica (PKI, Public Key Infrastructure)
DFS (Distributed File System, file system distribuito) basato sui domini
Considerazioni particolari per il deployment nelle filiali
Microsoft ha elaborato una serie di considerazioni particolari per il deployment di Active Directory nelle filiali. Di seguito
vengono illustrate alcune caratteristiche tipiche degli ambienti di filiale.
•
•
•
Numerose località fisiche che devono eseguire repliche dei dati Active Directory.
•
Connessioni di rete lente tra le filiali e il sito centrale (hub).
Pochi utenti per ogni località.
Topologia di rete “hub e spoke”, nella quale le varie filiali utilizzano la connessione a un sito centralizzato anche per
comunicare con le altre sedi dell'organizzazione.
Considerate le possibili implicazioni di questi requisiti, Microsoft ha elaborato ulteriori documenti che si occupano più
approfonditamente del deployment di Active Directory negli ambienti di filiale. Per ulteriori informazioni, consultare la guida
Active Directory Branch Office Planning Guide, disponibile on-line all'indirizzo:
http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/branchoffice/default.asp. Essa è stata ideata come
complemento della presente guida Progettazione ottimale di Active Directory per la gestione delle reti Windows.
Considerazioni particolari per il deployment di Exchange 2000
In questa guida vengono fornite informazioni utili per progettare un deployment di Active Directory che possa prevedere anche
l'impiego di Exchange 2000. Tuttavia, non sono incluse le informazioni necessarie per eseguire il deployment di Exchange
2000 integrato in Active Directory.
Per ulteriori dettagli, vedere Microsoft Exchange 2000 Server Upgrade Series all'indirizzo
http://www.microsoft.com/technet/itsolutions/guide/default.asp.
Informazioni su questa guida
Il presente documento è destinato a professionisti del settore IT che devono partecipare a un progetto di pianificazione e
deployment di Active Directory.Descrive un approccio ottimale alla progettazione dell'architettura di Active Directory, poiché
unisce indicazioni aziendali a indicazioni tecniche al fine di ridurre al minimo il tempo e l'impegno necessari per implementare
Active Directory nelle organizzazioni. La guida contiene inoltre alcuni fogli di lavoro utili per registrare i dati essenziali del
progetto.
Approccio ottimale
L'approccio ottimale qui presentato si basa sull'esperienza acquisita dai team di sviluppo di Active Directory di organizzazioni
che hanno già implementato Active Directory. Questo approccio abbrevia i tempi di pianificazione, poiché:
•
•
Favorisce la realizzazione di architetture Active Directory standard già collaudate.
•
•
Chiarisce le fasi principali e l'ordine che queste devono seguire, mediante diagrammi di flusso e fogli di lavoro.
È incentrato su scelte di progettazione che hanno dimostrato la propria validità nell’attività di gestione del NOS
Windows.
Esemplifica alcuni scenari a sostegno dei concetti di base utilizzati nella progettazione.
Ambito del documento
Sebbene le indicazioni contenute nel presente documento siano adeguate alla maggior parte dei progetti di deployment per la
gestione del NOS, esse sono state sottoposte a testing e convalidate soprattutto in ambienti con le caratteristiche seguenti:
•
•
•
Meno di 100.000 utenti.
Meno di 200 località fisiche.
In caso di ambienti che superano le cifre indicate, è consigliabile ricorrere ai servizi di un'azienda di consulenza che
abbia esperienza nel deployment di Active Directory in ambienti più complessi.
Utilizzo della guida
Per ogni fase della progettazione, ad esempio per la creazione dell'architettura della foresta, è incluso un diagramma di flusso
del processo e un elenco di attività da eseguire. È consigliabile progettare l'architettura di Active Directory seguendo l'ordine
indicato. Tenere presente che ogni fase del processo può implicare l'inserimento di nuovi membri nei team, che potranno
essere responsabili di alcune decisioni. Ogni membro deve registrare le decisioni relative alla progettazione nei fogli di lavoro
forniti. Può inoltre rivelarsi utile tagliare e incollare parti della guida all'interno del documento di progettazione, in modo che gli
eventuali nuovi membri possano comprendere le decisioni prese in precedenza.
È consigliabile non procedere alla fase o all'attività successiva prima di aver compilato per intero i fogli di lavoro forniti e prima
che tutti i singoli responsabili abbiano approvato le scelte effettuate. Ogni foglio di lavoro si basa sulle informazioni e le
decisioni registrate nel foglio di lavoro precedente. Se si utilizza la guida alle metodologie ottimali per il deployment di Active
Directory, tenere presente che nella fase effettiva di deployment si farà riferimento a questi fogli di lavoro.
Prima di procedere con la progettazione, controllare di:
•
•
Aver definito e compreso gli obiettivi aziendali relativi al deployment di Active Directory.
Aver ottenuto il supporto a livello dirigenziale per l'implementazione di una rete Windows gestita mediante Active
Directory.
Il deployment dell'infrastruttura Active Directory può interessare sia l'area tecnologica che quella delle specifiche attività
aziendali. Pertanto, la possibilità di proseguire la progettazione dipenderà dall'abilità di comunicare il valore di Active Directory
a coloro che prendono le decisioni in merito ai settori IT e aziendali.
Destinatari della guida
Il presente documento è destinato a professionisti del settore IT che devono partecipare al progetto di pianificazione e
deployment di Active Directory, quindi architetti, project manager, integratori di sistemi e consulenti.
Poiché Active Directory è concepito come infrastruttura per l'intera azienda, il team di progettazione coinvolgerà molte
persone. Nella guida verranno indicati i responsabili necessari nelle varie fasi del progetto. I team che si occupano della
progettazione dovranno ottenere il consenso di tali responsabili in merito alle decisioni che incideranno sul settore aziendale
che rappresentano. Nella maggior parte delle aziende, ad esempio, il deployment di Active Directory richiede l'integrazione con
un'infrastruttura DNS già esistente. Chi gestisce questa infrastruttura ha un'importanza cruciale per la riuscita del progetto.
Allo stesso tempo, è opportuno ridurre al minimo i team, per facilitare il raggiungimento di decisioni comuni.
È molto importante notare che il deployment di Active Directory nel ruolo di gestione di una rete Windows va condotta a livello
aziendale e non a livello di reparto. Pertanto, un amministratore di reparto che desideri installare Active Directory deve
prendere contatto con l'amministratore del settore IT aziendale. Se manca questo tipo di rapporto, si potranno riscontrare
difficoltà future nell'integrare il tipo di installazione eseguito nel reparto con quello eseguito nell'intera azienda.
Ruoli nel progetto
In un tipico deployment di Active Directory sono coinvolte molte persone, pertanto è importante stabilire fin dall'inizio due
ruoli: quello di architetto di sistemae quello di project manager. In un'organizzazione di grandi dimensioni, tali ruoli possono
essere condivisi da più persone. Nella tabella 1 sono riepilogati i ruoli essenziali nella progettazione di Active Directory.
Tabella 1 Ruoli nella progettazione di Active Directory
Ruolo di
progettazione
Responsabilità
Descrizione
Architetto di sistema
Progettazione
tecnica
Specialista o consulente responsabile delle decisioni
tecniche. Garantisce che il progetto rispetti appieno
gli obiettivi aziendali.
Project manager
Pianificazione del
processo di
progettazione
È il punto di raccordo che coordina l'avanzamento
della progettazione, coinvolgendo le persone adeguate
e raccogliendone l'approvazione. È responsabile della
pianificazione e della tempistica necessaria a supporto
della progettazione.
Architetto di sistema
Per ogni foresta è necessaria la presenza di un architetto che supervisioni la progettazione e il processo di migrazione di Active
Directory. Candidato ideale è un architetto IT o un pianificatore di sistemi IT che abbia acquisito una precedente esperienza
nella gestione di directory. In caso contrario, potrebbe essere necessario rivolgersi a un consulente esterno che abbia
esperienza con la progettazione e il deployment di Active Directory. La presenza di un consulente esterno può rappresentare
un'esperienza importante e apportare una nuova prospettiva al team di progetto; può rivelarsi estremamente utile soprattutto
quando si opera su problematiche che riguardano più aziende.
Le responsabilità dell'architetto di sistema includono:
•
•
•
•
La progettazione di Active Directory.
La definizione delle logiche relative alle decisioni chiave del progetto.
La verifica del raggiungimento degli obiettivi aziendali.
La proposta di soluzioni alternative che potrebbero riflettere meglio le esigenze aziendali, se necessario.
Il progetto finale deve necessariamente combinare gli obiettivi aziendali e le decisioni tecniche. Pertanto l'architetto di sistema
dovrà rivedere le decisioni, confrontarle con gli obiettivi aziendali e verificare che i due aspetti siano sulla stessa linea.
Project manager
Per promuovere un efficace processo di progettazione, potrebbe essere necessario nominare una persona o un piccolo
comitato a cui affidare l'incarico di project manager. Il compito del project manager è quello di facilitare la cooperazione tra
unità aziendali, nonché con i gruppi che gestiscono tecnologie quali DNS, reti e Windows NT. Le responsabilità del project
manager includono:
•
•
La pianificazione di base del progetto, ad esempio la tempistica e il budget.
L'avanzamento della progettazione di Active Directory.
•
•
•
Il coinvolgimento delle persone più adatte in ogni fase del processo di progettazione.
Essere il punto di raccordo per la progettazione della directory.
Raccogliere il consenso dei team.
Progettazione di Active Directory: concetti principali
Durante l'approccio alla progettazione, è necessario tenere conto del fatto che si elaborerà tanto un modello logico quanto un
modello fisico.
Modelli logici
Active Directory consente agli amministratori di organizzare gli elementi di una rete, quali utenti, computer, periferiche e così
via, in una struttura gerarchica ad albero, basata sul concetto di relazione tra contenitori. Il contenitore Active Directory di
livello superiore è detto foresta. All'interno delle foreste sono presenti i domini. Nell'ambito dei domini si trovano le unità
organizzative (UO). Questa struttura è chiamata modello logico perché è progettata indipendentemente dalla maggior parte
degli aspetti fisici del deployment, quali ad esempio il numero di repliche necessarie nell'ambito di ogni dominio e la topologia
di rete.
Per facilitare la gestione di un numero elevato di oggetti, Active Directory supporta inoltre il concetto di delega amministrativa
al livello di contenitore. Mediante la delega, i proprietari possono trasferire l'autorità sugli oggetti ad altri utenti o gruppi. Si
tratta di un concetto fondamentale perché consente di distribuire la gestione di un numero elevato di oggetti a più persone
affidabili, che avranno il compito di gestire gruppi e tipi di oggetti specifici.
Nella figura 1 è illustrata la distribuzione degli utenti in un'organizzazione fittizia situata nel Nord America. In questo esempio,
una sola foresta Active Directory contiene tutti gli utenti, i computer, le periferiche e altre entità dell'organizzazione. Per
supportare un tipo di amministrazione su base geografica, l'organizzazione ha creato cinque domini (Ovest, Regione Centrooccidentale, Nordest, Sudest e America Latina) come divisioni di primo livello della foresta. Per supportare un'ulteriore delega,
l'organizzazione ha suddiviso la divisione Ovest in unità organizzative, rappresentate dalle linee tratteggiate.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 1 Delega dell'amministrazione all'interno di un'organizzazione
In questo esempio, l'organizzazione ha delegato alcuni aspetti dell'amministrazione al responsabile di divisione del dominio
Ovest. A sua volta, questo responsabile ha delegato alcuni aspetti dell'amministrazione ai responsabili delle proprie sottodivisioni. Allo stesso modo, Active Directory supporta una struttura gerarchica che crea livelli di delega amministrativa per
supportare il servizio di directory e tutti gli oggetti della foresta.
Durante la progettazione del modello logico, attuata seguendo le indicazioni dettagliate fornite più avanti, sarà necessario
stabilire i confini tra foreste, domini e unità organizzative.
Modelli fisici
Dopo aver progettato il modello logico, è la natura fisica delle rete che determina le altre attività da eseguire. Ad esempio,
potrebbe essere necessario decidere come gestire le repliche dei dati del dominio e del catalogo globale. È inoltre necessario
descrivere la topologia di rete a livello di subnet, in modo da configurare un percorso ottimizzato per le comunicazioni
all'interno della rete LAN, ad esempio il traffico di replica di Active Directory.
Particolare attenzione va posta sulle decisioni relative alla replica, poiché hanno effetto sul traffico di rete e sulla visibilità dei
dati. Ad esempio, i domain controller non replicano i dati della directory da una foresta all'altra. Quelli che ospitano il catalogo
globale includono una descrizione parziale di ogni oggetto della foresta e condividono queste informazioni con tutta la foresta,
ma solo con gli altri domain controller che contengono il catalogo globale. Nell'ambito di ogni dominio, tutti gli aggiornamenti
dei dati degli oggetti inclusi nel dominio vengono automaticamente replicati in ogni domain controller del dominio, ma non nei
domain controller di altri domini.
In questa guida vengono fornite istruzioni dettagliate per tutte le decisioni e le procedure correlate ai modelli fisici.
Ulteriori informazioni
Questa guida offre una quantità limitata di informazioni di base sui concetti, sulla tecnologia e sulla terminologia relativa ad
Active Directory. Se non si ha familiarità con i concetti relativi ad Active Directory presentati in questa guida, è consigliabile
leggere e approfondire le informazioni contenute nei documenti di seguito indicati.
•
Active Directory Overview, disponibile on-line all'indirizzo:
http://www.microsoft.com/windows2000/server/evaluation/features/dirlist.asp
•
Active Directory Architecture, disponibile on-line all'indirizzo:
http://www.microsoft.com/windows/
Per ulteriori informazioni di base, è inoltre consigliata la lettura di:
•
The Active Directory Glossary, disponibile on-line all'indirizzo:
http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/glossary.asp
•
Active Directory Users, Computers, and Groups, disponibile on-line all'indirizzo:
http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/adusers.asp
•
La sezione Directory Services della raccolta Windows 2000 Technical Library è disponibile on-line all'indirizzo:
http://www.microsoft.com/windows2000/technologies/directory/default.asp
•
Il capitolo 1 "Active Directory Logical Structure" di "Distributed Systems Guide" di Windows 2000 Server Resource
Kit.
•
Il capitolo 9 "Designing the Active Directory Structure" di "Deployment Planning Guide" di Windows 2000 Server
Resource Kit, disponibile on-line all'indirizzo:
http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/reskit/deploy/part3/chapt-9.asp
Parte I - Definizione del numero di foreste nell'organizzazione
Definizione del numero di foreste nell'organizzazione
Il contenitore di livello più elevato presente in Active Directory è la foresta. Come prima fase della progettazione, l'architetto e
il project manager di Active Directory devono determinare il numero di foreste necessarie nell'organizzazione. Considerato che
è il modello più facile da gestire, è in genere consigliabile optare per una struttura a foresta unica. Tuttavia, un deployment
con struttura a foresta unica presenta anche varie limitazioni e quindi non è adatto per tutte le organizzazioni.
Ad esempio, coloro che all'interno dell'organizzazione gestiscono l'infrastruttura IT per le divisioni autonome potrebbero voler
assumere il ruolo di proprietario della foresta e procedere con una progettazione autonoma dell'architettura della foresta. In
altre situazioni, tuttavia, i potenziali proprietari di foreste potrebbero scegliere di unire le loro divisioni autonome in una
foresta singola, per ridurre il costo di progettazione ed esercizio di Active Directory o per facilitare la condivisione delle risorse.
Nella parte I della presente guida vengono fornite indicazioni sulle problematiche e sui compromessi impliciti nello stabilire il
numero di foreste necessarie per il tipo di deployment scelto.
Ruolo delle foreste nelle architetture delle reti Windows
Per foresta si intende una singola istanza di un deployment di Active Directory. Per definizione, la foresta è autonoma dal
punto di vista amministrativo da qualsiasi altro deployment di Active Directory all'interno dell'organizzazione. In altre parole,
poiché rappresenta il livello più alto di proprietà e controllo, la foresta rappresenta un confine amministrativo protetto in
relazione alla gestione di Active Directory. Nell'ambito di tale confine è presente una serie di elementi condivisi, che sono:
•
Schema.
Lo schema di Active Directory include informazioni su ogni classe di oggetti e su tutti gli attributi di ogni classe di
oggetti che è possibile memorizzare nella foresta. Ad esempio, ogni account utente rappresenta un'istanza della
classe utente così come è stata definita nello schema. La descrizione dello schema è memorizzata in una porzione del
database della directory che viene replicata in ogni domain controller della foresta.
•
Oggetti di configurazione.
Il deployment di Active Directory viene descritto da un insieme di oggetti di configurazione che contengono i dati che
definiscono gli elementi dell'infrastruttura e della topologia quali domini, siti e collegamenti tra i siti. Anche gli oggetti
di configurazione vengono memorizzati in una porzione del database della directory che viene replicata in ogni
domain controller della foresta.
•
Catalogo globale degli oggetti ricercabili di una directory.
Gli amministratori possono specificare alcuni domain controller affinché conservino, oltre alle repliche dei dati dei
domini, una copia parziale di ogni oggetto della foresta. I dati vengono conservati in una porzione del database della
directory detta catalogo globale. Il catalogo globale consente la ricerca veloce ed efficiente di oggetti nell'intera
foresta. In ogni domain controller che ospita il catalogo globale della foresta, indipendentemente dal dominio a cui
appartiene, è presente una copia identica del catalogo.
•
Relazioni di trust tra tutti i domini della foresta.
Active Directory crea automaticamente relazioni di trust bidirezionali e transitive tra tutti i domini di una foresta.
Ogni computer membro è in grado di riconoscere e autorizzare l'accesso di ogni utente o gruppo di qualunque
dominio della foresta.
Poiché una foresta può includere milioni di oggetti, sono poche le ragioni tecniche che impediscono l'esecuzione del
deployment di una foresta unica per soddisfare le esigenze aziendali. Tuttavia, a seconda del modello amministrativo
dell'organizzazione, potrebbe essere necessario creare più foreste. Durante la prima fase della progettazione di Active
Directory, l'architetto incaricato determinerà il numero di foreste necessario all'organizzazione per raggiungere gli obiettivi
aziendali e nominerà un proprietario per ogni nuova foresta.
Elementi da considerare nella determinazione del numero di foreste
L'architetto e il project manager di Active Directory sono responsabili del completamento del piano della/e foresta/e per
l'organizzazione. Tale piano deve includere l'elenco delle foreste da creare, che contenga anche i seguenti dati:
•
•
Nome del proprietario di ogni foresta.
Ambito di ogni foresta.
Differenza fra la proprietà dei servizi e la proprietà dei dati
Prima di poter comprendere i concetti di proprietà presentati in questa guida, è necessario aver compreso appieno la
differenza tra proprietà dei servizi e proprietà dei dati. Prima dell'avvento di Active Directory, il modello amministrativo di
Windows NT definiva il dominio come un gruppo di oggetti gestito da amministratori. Questo documento introduce il concetto
di amministrazione IT ripartita. In Windows 2000 esistono due tipi di amministratori: gli amministratori di dati (o di oggetti) e
gli amministratori di servizi (o di directory).
Il vantaggio offerto dalla scelta di uno stile di amministrazione ripartito consiste nel fatto che le singole unità aziendali non
devono addestrare il personale per supportare il servizio di directory. Possono invece concentrarsi sulle proprie attività
aziendali e occuparsi soltanto della gestione dei dati della directory.
Per gestire gli oggetti della directory, gli amministratori dei dati devono eseguire funzioni e disporre di autorizzazioni simili a
quelle degli attuali amministratori di Windows NT. Per quanto riguarda Windows 2000, gli amministratori dei dati supportano
gli utenti e i computer della foresta eseguendo funzioni quali:
•
•
Aggiunta e rimozione di computer, utenti, gruppi e unità organizzative.
Creazione delle impostazioni dei criteri di gruppo.
Gli amministratori dei servizi non corrispondono ad alcun ruolo amministrativo specifico del modello di dominio di Windows NT.
Sono responsabili della fornitura del servizio di directory, dell'amministrazione dei domini, della proprietà dei domain controller
e della gestione della configurazione della directory. Per Windows 2000 Active Directory, gli amministratori dei servizi
supportano l'infrastruttura delle foreste eseguendo funzioni quali:
•
•
•
•
•
•
Creazione o rimozione dei domini.
Modifica dello schema.
Installazione e rimozione dei domain controller.
Gestione della configurazione dei domain controller.
Monitoraggio delle condizioni dei domain controller.
Gestione della topologia dei siti.
Separando l'amministrazione dei dati dall'amministrazione dei servizi, un amministratore può mantenere un completo controllo
di tutti gli utenti e di tutti i computer di una divisione, delegando l'amministrazione dei servizi a un altro gruppo. Questa
distinzione consente alle organizzazioni di maggiori dimensioni di sfruttare i vantaggi di una singola directory centrale,
conservando le procedure aziendali correnti.
Nelle sezioni seguenti del documento verrà tenuto conto della distinzione tra proprietari dei servizi e proprietari dei dati.
Analisi del ruolo di proprietario della foresta
Il proprietario della foresta è responsabile della fornitura dei servizi directory alla rete Windows. Tra le sue responsabilità sono
incluse:
•
•
La proprietà dei contenitori dello schema e della configurazione.
La proprietà dei dati inclusi nel dominio radice della foresta.
Nella tabella 2 vengono elencati questi e altri ruoli assegnati al proprietario della foresta e le responsabilità associate a ogni
ruolo. Il proprietario della foresta controlla la foresta mediante tre gruppi di protezione:
•
•
•
Domain Admins del dominio radice della foresta
Enterprise Admins
Schema Admins
Tabella 2 Ruoli e responsabilità del proprietario della foresta
Ruolo
Responsabilità
P roprietario del servizio per i domain controller
Controlla la configurazione dei domain controller
di tutta la foresta per gestire gli aspetti relativi
alla replica.
del dominio radice della foresta
Proprietario e amministratore dei dati presenti
nel dominio radice della foresta
Controlla l'appartenenza ai gruppi di protezione
Domains Admins, Enterprise Admins e Schema
Admins del dominio radice della foresta.
Supervisione amministrativa per tutti i dati del
dominio
Mediante il gruppo Enterprise Admins, il
proprietario della foresta può correggere ogni
errore che si verifica nella directory. Sebbene sia
possibile bloccare l'accesso amministrativo del
gruppo Enterprise Admins ai domini non radice,
questa procedura non è consigliata.
Proprietario e amministratore dello schema
Mediante il gruppo Schema Admins:
• Imposta i criteri per le estensioni dello schema
• Imposta il processo di estensione dello schema
• Controlla chi estende lo schema
Proprietario e amministratore dei criteri della
configurazione
Mediante il gruppo Enterprise Admins:
• Funge da custode dei nuovi domini della
foresta
• È il proprietario e l’amministratore della
topologia dei siti
Nota È consigliabile che il proprietario della foresta sia una persona considerata altamente affidabile. Non esistono ragioni
valide per impedire l'accesso del proprietario della foresta ai dati dei domini non radice. Nel caso in cui si verifichi un errore
grave nei dati di un dominio, a causa di un'azione intenzionale o meno, il proprietario della foresta deve essere in grado di
accedere al dominio per risolvere il problema.
Relazione tra i ruoli dei proprietari dei servizi
Il modello ottimale prevede la creazione di nuovi ruoli amministrativi in conseguenza della gestione della directory e della
delega amministrativa dei dati nell'intera foresta. Nella figura 2 vengono illustrati i rapporti consigliati di responsabilità tra i
ruoli amministrativi IT. Questi rapporti fanno riferimento alla delega della responsabilità del servizio di directory e non sono
necessariamente correlati alla struttura gerarchica dell'organizzazione. Ad esempio, il proprietario del servizio DNS fornisce e
configura i servizi DNS in base a quanto specificato dal proprietario della foresta ed eventualmente da ogni proprietario dei
domini della foresta.
Il proprietario della foresta delega la gestione dei singoli domini a un gruppo di proprietari, la gestione della topologia dei siti a
un proprietario della topologia dei siti e la gestione del servizio DNS a un proprietario del servizio DNS. A sua volta, ogni
proprietario di dominio delega la gestione di ogni unità organizzativa a un gruppo di proprietari di unità organizzative e il
servizio DNS al proprietario del servizio DNS.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 2 Gerarchia dei ruoli amministrativi del servizio di directory per un'unica foresta con quattro domini
Nella tabella 3 i principali ruoli amministrativi di Active Directory sono suddivisi tra ruoli di proprietà dei servizi e ruoli di
proprietà dei dati.
Tabella 3 Ruoli di proprietà dei servizi e dei dati di Active Directory
Proprietari dei servizi
Proprietari dei dati
Proprietario della foresta
Proprietari di dominio
Proprietari del servizio DNS
Proprietari della topologia dei siti
Proprietario della foresta (per il dominio radice)
Proprietari delle unità organizzative
In una foresta di grandi dimensioni, ogni ruolo di proprietario può essere condiviso da un gruppo di amministratori, ognuno
con l'autorità amministrativa necessaria per eseguire i compiti richiesti. In un'organizzazione più piccola, a una sola persona
possono essere affidati più ruoli.
Nota Solo il proprietario della foresta può nominare un proprietario di dominio. I proprietari di dominio dispongono del
controllo amministrativo sui domain controller presenti nella foresta e pertanto devono essere altamente affidabili.
Modelli ottimali di foreste
Il modello ottimale di foresta si basa sulle procedure aziendali nel settore IT. I tre modelli generici di foresta consigliati per
un'organizzazione sono i seguenti:
•
•
•
Modello a foresta globale unica.
Modello a sottoscrizione.
Modello a foreste multiple.
Architettura a foresta unica
Nel modello a foresta unica, un'organizzazione sceglie di inserire e gestire tutti gli oggetti della directory presenti
nell'organizzazione utilizzando un'unica foresta. Si tratta del modello ideale, perché implica il carico minore di lavoro
amministrativo. Nella figura 3 viene illustrata un'architettura a foresta unica per un'organizzazione con tre divisioni. In questo
tipo di architettura, tutte e tre le divisioni fanno parte di un'unica foresta.
Figura 3 Architettura a foresta unica per un'organizzazione con tre divisioni
Architettura di foresta a sottoscrizione
Nell'architettura di foresta a sottoscrizione, esistono alcune foreste autonome al livello di divisione, ma la maggior parte delle
divisioni è unificata in una foresta più ampia gestita da un'organizzazione IT centralizzata. Le foreste a sottoscrizione offrono il
vantaggio di fornire un deployment rapido per le divisioni che hanno adottato già da tempo Active Directory, consentendo al
tempo stesso alle altre unità aziendali, preoccupate per la sicurezza o per le conseguenze derivanti dalla condivisione delle
responsabilità, di progettare e gestire le proprie foreste.
Nella figura 4 viene illustrata un'architettura di foreste a sottoscrizione per un'organizzazione con tre unità aziendali.
Nell'esempio, due unità aziendali hanno scelto di partecipare a una singola foresta, mentre la terza divisione ha creato una
seconda foresta.
Figura 4 Architettura ibrida per un'organizzazione con tre divisioni
Architettura a più foreste
In un'architettura a più foreste, la maggior parte delle unità aziendali di un'organizzazione sceglie di eseguire il deployment di
una propria foresta Active Directory. Questo tipo di architettura è funzionale nelle organizzazioni con unità aziendali che
desiderano o hanno necessità di conservare la propria autonomia amministrativa. Il modello presenta il maggior carico di
lavoro amministrativo possibile.
Nella figura 5 viene illustrata un'architettura a più foreste per un'organizzazione con tre divisioni. Ogni unità aziendale gestisce
nel tempo la propria infrastruttura IT. Di conseguenza, ogni unità aziendale sceglie di progettare e installare una foresta Active
Directory indipendente.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 5 Un'architettura a più foreste costituita da tre foreste Active Directory
Processo di progettazione delle foreste
La figura 6 illustra il processo di progettazione delle foreste. In questa fase, il project manager e l'architetto di Active Directory
determinano il numero di foreste da progettare per l'organizzazione. L'ideale è l'architettura a foresta unica, poiché
rappresenta il minore carico di lavoro amministrativo. Tuttavia, a causa delle diverse limitazioni che implica, la foresta unica
non è sempre adatta. L'obiettivo è comunque quello di ridurre il numero totale di foreste. Per stabilire il numero di foreste
necessarie:
1.
2.
Identificare tutti coloro che svolgeranno il ruolo di fornitori del servizio di directory.
Assegnare le divisioni a una foresta in base a fattori tecnici o organizzativi.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 6 Diagramma di flusso per la definizione del numero di foreste nell'organizzazione
Identificazione dei candidati al ruolo di fornitori del servizio di directory
A questo punto è necessario determinare il livello più elevato di amministratori IT nell'ambito dell'organizzazione, che avranno
l'incarico di fornire i servizi di directory per una rete Windows. Spesso all'interno di un'azienda esistono più soggetti in grado di
fornire servizi di directory.
L'organizzazione può disporre di un modello IT centralizzato con un dirigente responsabile della gestione delle informazioni,
che delega l'amministrazione IT agli amministratori delle divisioni, in base alle necessità. In questa situazione esiste un solo
candidato all'incarico di fornitore del servizio di directory, pertanto appare più indicata la scelta di un'unica foresta.
L'organizzazione, d'altro canto, può avere un modello IT decentrato, nel quale gli amministratori IT a livello di divisione hanno
la responsabilità dell'amministrazione della rete e la delega nell'ambito delle loro organizzazioni autonome. Nelle organizzazioni
con autorità distribuita si hanno spesso responsabili della gestione delle informazioni di pari livello. In questa situazione
esistono più candidati all'incarico di fornitore del servizio di directory, pertanto appare più indicata la scelta di più foreste.
L'organizzazione può avere già eseguito il deployment di Active Directory per altri scopi. In questo caso va considerato come
possibile candidato alla fornitura del servizio di directory ogni attuale proprietario di foresta. La directory esistente supporta i
servizi di messaggistica e i servizi di rete Windows per un numero limitato di unità aziendali o per altre finalità. La possibile
trasformazione della struttura Active Directory già esistente in una base per i servizi di directory estesi dipende dalle finalità e
dal modo in cui è stato eseguito il deployment.
Assegnazione delle foreste
Determinare il numero minimo di foreste necessarie all'organizzazione per soddisfare i requisiti aziendali. Per stabilire il
numero corretto di foreste per l'organizzazione:
1.
2.
3.
Se è stato identificato un solo candidato alla fornitura del servizio di directory, questa persona, che diventerà il
proprietario della foresta, potrà procedere con la parte II del progetto, ovvero con la creazione dell'architettura della
foresta.
Se sono stati individuati più candidati, è necessario determinare se è possibile designare un candidato come
proprietario della foresta e gli altri come partecipanti alla foresta. La sezione seguente "Partecipazione a una foresta
unica o a una foresta a sottoscrizione" offre indicazioni utili per questo tipo di decisione.
Nel caso in cui i possibili fornitori del servizio di directory non riescano ad accordarsi su una foresta unica, è
necessario stabilire se un'architettura a sottoscrizione sia funzionale per i possibili candidati.
Nota Stabilire un termine entro il quale tutti i possibili fornitori del servizio di directory debbano decidere se unirsi o
meno a una foresta. Se la creazione di una foresta unica richiede la modifica delle attuali procedure aziendali e rende
le operazioni più lunghe di quanto previsto, è consigliabile creare una foresta autonoma.
4.
Nel caso in cui il tentativo di implementare un modello a sottoscrizione non riesca, è consigliabile che ogni candidato
crei una foresta distinta.
Le conseguenze di tali decisioni sono descritte in dettaglio nella sezione seguente "Creazione di una foresta
autonoma".
Può accadere che un possibile fornitore non abbia sufficiente interesse, budget o potere per procedere con il deployment. In
questo caso, tale candidato può scegliere di non eseguire immediatamente il deployment di Active Directory ma pensare a un
deployment successivo, senza impedire agli altri candidati di procedere con la propria progettazione.
Partecipazione a un foresta unica o a una foresta a sottoscrizione
Nel caso in cui esista già una foresta o se un gruppo dell'organizzazione si offre per gestire la directory per conto di altre
divisioni, è opportuno che i candidati alla fornitura del servizio di directory entrino a far parte della foresta già esistente.
Scegliere di diventare proprietari o partecipanti alla foresta implica un diverso livello di responsabilità. Chi partecipa alla
foresta, in qualità di proprietario dei dati, è responsabile della gestione degli stessi, mentre il proprietario della foresta, in
qualità di proprietario del servizio, è responsabile della gestione del servizio di directory. Ad esempio, il proprietario dei dati
garantisce che la password di un utente sia correttamente impostata, mentre il proprietario del servizio garantisce che questa
sia replicata in tutti i domain controller. Nella tabella 4 vengono confrontate le responsabilità che si hanno quando si è
proprietari o partecipanti a una foresta.
Tabella 4 Confronto tra le responsabilità dei proprietari e dei partecipanti a una foresta
Proprietario di foresta
Partecipante a una foresta
• Controllo della fornitura del servizio.
• Responsabile della qualità del servizio.
• Delega la gestione dei dati a singoli proprietari
dei dati.
• Outsourcing della fornitura del servizio.
• Gestione dei soli dati della divisione.
Con la sottoscrizione dei servizi di directory forniti da un altro gruppo, si riducono notevolmente i costi amministrativi, grazie
alle caratteristiche seguenti:
•
•
Assenza di un proprio processo di progettazione.
•
Nessun isolamento dei propri utenti dagli utenti, dalle risorse e dai servizi di altre foreste.
Nessuna duplicazione delle operazioni di gestione della directory, quali:
o Team di esperti in pianificazione del deployment e delle operazioni relative alla directory.
o Gestione dell'hardware dei domain controller.
o Gestione della struttura della directory.
Una foresta condivisa è funzionale in molte situazioni e semplifica in maniera notevole la gestione di Active Directory. La
condivisione di una configurazione unica e coerente in tutti i domini di una foresta presenta vantaggi specifici, tra i quali:
•
•
•
•
Le modifiche allo schema devono essere apportate una sola volta e avranno effetto su tutti i domini.
Le modifiche alla configurazione devono essere apportate una sola volta e avranno effetto su tutti i domini.
Un unico catalogo globale comune per tutti gli utenti.
Relazioni di trust automatiche fra tutti i domini.
Le procedure aziendali in uso determinano il valore e la fattibilità della condivisione di una foresta.
Alcuni candidati al ruolo di fornitori del servizio di directory potrebbero scegliere di non partecipare a un'architettura a foresta
condivisa perché hanno esigenze di protezione diverse o limitazioni di rete e amministrative che non possono essere risolte con
questo tipo di struttura. Nella tabella 5 vengono riepilogate le caratteristiche presenti nella maggior parte delle foreste
condivise.
Tabella 5 Caratteristiche di una foresta condivisa
Fattore
Caratteristiche di una foresta condivisa
Necessari
Protezione
• Affidabilità del proprietario della foresta e di
tutti i proprietari di dominio della foresta.
• Tutti i domain controller si trovano in luoghi
protetti oppure il rischio implicato in domain
controller che non si trovano in luoghi protetti è
accettabile.
Amministrazione
• È possibile accettare lo schema comune e i
criteri di configurazione impostati dal proprietario
della foresta.
Risoluzione dei nomi
• Il servizio DNS è in grado di risolvere i nomi
dell'intera foresta.
Consigliati
Rete
• Nessun firewall di separazione tra i domain
controller.
• Nessuna periferica NAT (Network Address
Translation) di separazione tra i domain
controller.
Collaborazione tra le organizzazioni
• Trust tra domini di varie organizzazioni già
esistenti.
• Le divisioni condividono già una vasta gamma
di risorse.
Organizzazione IT
• Gruppo di infrastrutture IT comune.
• Se la gestione del servizio di directory viene
eseguita in outsourcing, deve coinvolgere un
unico fornitore.
Importante Ogni domain controller della foresta include una copia in scrittura dei contenitori dello schema e della
configurazione. Se qualcuno è in grado di installare prodotti software o di accedere fisicamente a un domain controller, sarà
anche in grado di aggirare le funzionalità di protezione incorporate in Windows 2000 e di apportare modifiche a tali contenitori.
Ciò rappresenta un rischio per la protezione dell'intera foresta. È pertanto consigliabile che:
•
Tutti gli amministratori, ad esempio gli amministratori di dominio, ovvero coloro che possono installare prodotti
software in un domain controller, siano altamente affidabili.
•
I domain controller siano tenuti in luoghi protetti.
La mancanza di una delle caratteristiche necessarie sconsiglia la condivisione della foresta. Un potenziale membro della foresta
potrebbe non rispondere a tutte le caratteristiche consigliate, ma tuttavia continuare a condividere una foresta. Tuttavia, se i
requisiti mancanti sono troppi, la partecipazione alla foresta potrebbe diventare difficoltosa dal punto di vista tecnico e quindi
meno vantaggiosa. La deviazione dalle caratteristiche indicate nella tabella 5 non è raccomandabile. Se la progettazione è
molto lontana da tali requisiti, è consigliabile affidarsi all'assistenza di un esperto.
Se si sceglie di partecipare a una foresta, verificare che la proprietà della stessa sia ben chiarita. Condividere la proprietà di
una foresta con un altro gruppo IT o suddividere la gestione tra più fonti esterne può comportare problemi organizzativi che è
sempre preferibile evitare.
Creazione di una foresta autonoma
Sebbene la condivisione di una foresta implichi numerosi vantaggi, questi sono proporzionali al livello di cooperazione e
collaborazione esistente tra le divisioni. In tutta probabilità, non è necessario progettare una foresta unica per l'organizzazione
se:
•
È necessaria l'autonomia.
È necessario disporre del pieno controllo sulla fornitura dei servizi oppure non è possibile accettare le condizioni poste
da un altro proprietario di foresta.
•
Di regola, non si collabora con altre divisioni.
Se vi è una forma di collaborazione, occorre specificarne la natura. Per collaborazione si intende lo scambio di posta
elettronica o simile, ad esempio l'accesso alle rispettive Intranet e alle condivisioni nonché la condivisione delle
applicazioni. Se le divisioni lavorano a stretto contatto, esse possono risiedere nella stessa foresta.
Se la collaborazione è un'eccezione e non la regola, è possibile configurare relazioni di trust con i domini in altre
foreste volta per volta. Ad esempio, è possibile limitare il livello di collaborazione tra le divisioni mediante l'impiego di
firewall.
•
I precedenti tentativi di deployment non sono riusciti a causa delle diverse culture o missioni all'interno di
un'organizzazione di vaste dimensioni.
Al momento di iniziare la progettazione della foresta, tenere presente che l'autonomia amministrativa implica dei costi. È
necessario bilanciare l'autonomia con l'efficienza della gestione.
Nota Le dismissioni possono creare incertezze su come procedere con la pianificazione della foresta. Ad esempio, è opportuno
domandarsi se la divisione che verrà dismessa debba essere inserita nella foresta o sia necessario pianificare una foresta a
parte. È consigliabile creare una foresta distinta per una divisione se si è assolutamente certi che tale divisione verrà
dismessa. Altrimenti, è meglio includerla, considerato che eseguire la migrazione della divisione in una nuova foresta nel caso
in cui la dismissione abbia esito positivo richiede lo stesso livello di impegno dell'unirla alla foresta nel caso in cui la
dismissione non abbia luogo.
Implicazioni della collaborazione tra foreste
Poiché ogni foresta è amministrata separatamente, l'aggiunta di ulteriori foreste all'architettura aumenta il carico di lavoro di
gestione dell'organizzazione. Al momento di decidere la creazione di una nuova foresta, confrontare le possibili conseguenze
elencate nella tabella 6 a fronte degli eventuali vantaggi. Se la collaborazione tra unità aziendali e divisioni non è frequente,
questi fattori potrebbero essere irrilevanti rispetto alla decisione da prendere.
Tabella 6 Implicazioni della collaborazione tra foreste
Modifica della funzionalità
Conseguenza
Nessuna relazione di trust transitiva automatica
Per accedere alle risorse di altre foreste, è
necessario stabilire relazioni di trust esplicite tra
i due domini interessati.
Nessuna autenticazione Kerberos
L'autenticazione tra foreste manca della delega
di autenticazione e della mutua autenticazione.
Nessun catalogo globale degli oggetti
Al fine di creare una singola vista di più foreste,
è necessario installare un software per la
sincronizzazione della directory, ad esempio
Microsoft Metadirectory Services. La presenza di
più cataloghi globali può incidere su alcune
applicazioni, ad esempio Exchange 2000.
Impossibile accedere con il nome utente in
formato email (User Principal Name)
Se l'account del computer e quello dell'utente si
trovano in foreste diverse, per identificare gli
utenti è necessario utilizzare i nomi nel formato
tradizionale.
Delega delle fasi successive ai proprietari di foresta
A questo punto della progettazione, risulta stilato l'elenco delle foreste e dei loro proprietari. Ognuno di essi può procedere
autonomamente alla fase successiva del processo di progettazione indicata nella "Parte II - Creazione dell'architettura della
foresta". Ogni proprietario di foresta dovrà designare un project manager e un architetto di Active Directory che supervisioni la
fase di progettazione della foresta stessa.
Nella figura 7 vengono illustrate le attività necessarie per la creazione di un'architettura di foresta. Ogni proprietario di foresta
designato crea un'architettura di Active Directory distinta.
Figura 7 Diagramma di flusso delle attività eseguite da ogni proprietario di foresta nella fase di progettazione
della foresta
Parte II - Creazione dell'architettura della foresta
Creazione dell'architettura dei domini
A questo punto della progettazione di Active Directory è già stato identificato il proprietario della foresta ed è pertanto
possibile procedere. Il passaggio successivo è rappresentato dalla progettazione del dominio radice della foresta e
dall'identificazione di tutti i relativi domini figlio.
Ruolo dei domini nelle architetture delle reti Windows
Un dominio costituisce una partizione della foresta Active Directory. Le foreste Active Directory vengono suddivise in più
domini per evitare la replica dei dati in punti in cui essa non è necessaria. In tal modo è possibile garantire la scalabilità
globale della directory in una rete in cui la disponibilità di larghezza di banda è limitata.
Il dominio Active Directory continua a fungere da confine amministrativo per la gestione degli oggetti, quali utenti, gruppi e
computer. Inoltre, esso supporta diverse funzioni essenziali correlate all'amministrazione. Nel contesto di un sistema operativo
di rete le importanti funzioni svolte da un dominio sono le seguenti:
•
Autenticazione.
In ogni dominio sono inclusi gli identificativi di base degli oggetti per la sicurezza, ad esempio utenti, gruppi e
computer, ai quali può essere accordato o negato l'accesso alle risorse della rete. Un utente può essere autenticato
solo da un domain controller che fa parte del dominio in cui è presente l'account dell'utente in questione.
•
Amministrazione basata sui criteri.
Active Directory risolve il problema della standardizzazione della gestione di centinaia di migliaia di oggetti di un
dominio mediante l'amministrazione basata sui criteri. Ad esempio, è possibile utilizzare i criteri di gruppo per
standardizzare le configurazioni degli utenti e dei computer. I criteri di gruppo possono essere creati e applicati nel
contesto di una migrazione a Windows 2000 o in qualsiasi momento successivo al deployment di Active Directory.
•
Criteri di protezione per gli account utente.
Un ristretto gruppo di criteri di protezione che si applica ad account utente univoci di dominio può essere impostato
solo dominio per dominio. Tra di essi:
o
o
o
•
Criteri di gestione delle password
Criteri di blocco degli account
Criteri dei ticket Kerberos
Funzionamento come directory per la pubblicazione di risorse condivise.
In Active Directory i servizi possono pubblicare le informazioni di connessione relative alle risorse condivise. Ad
esempio, in un dominio è possibile pubblicare le risorse di stampa per facilitare le ricerche eseguite dagli utenti.
Confronto tra i domini Active Directory e quelli Windows NT
Le organizzazioni che utilizzano Windows NT di solito configurano più domini. L'esistenza di questi ultimi consente di gestire
aziende con organizzazioni diversificate, divisioni geografiche differenti, nonché di aggirare le limitazioni di Windows NT. Nei
domini Windows NT sono state rilevate essenzialmente tre limitazioni:
•
•
•
Dimensioni ridotte dei database degli account.
Riferimento al solo Domain Controller Primario (PDC, Primary Domain Controller) per gli aggiornamenti dei database.
Impossibilità di delegare l'amministrazione all'interno di un dominio.
Per ovviare a questi limiti, le organizzazioni di grandi dimensioni hanno di solito eseguito il deployment di Windows NT
utilizzando per gli account uno o più domini utente (MUD, Master User Domain) e numerosi domini di risorse (RD, Resource
Domain). Gli amministratori presenti in tali domini hanno creato delle relazioni di trust per collegare gli utenti e le risorse in
tutta l'organizzazione. Nella figura 8 viene mostrata la struttura adottata di solito dalle organizzazioni per il modello
Master/Resource Domain di Windows NT.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 8 Modello di gestione di domini multipli in Windows NT con relazioni di trust tipiche
Windows 2000 Active Directory non presenta alcuna di queste limitazioni. Pertanto molti domini creati in Windows NT possono
essere consolidati e ridotti a pochi domini Active Directory.
Elementi della progettazione dei domini
Il proprietario della foresta è responsabile del completamento della progettazione dei domini per conto della propria
organizzazione. Nella progettazione è necessario includere quanto segue:
•
•
Nome del dominio radice della foresta.
•
L'elenco dei domini Windows NT esistenti da aggiornare o consolidare.
Elenco di tutti i domini con:
o Nome del dominio.
o Ambito del dominio.
o Numero di utenti inclusi nel dominio.
Ruolo del proprietario di un dominio
Il proprietario di un dominio si occupa dell'amministrazione del servizio di directory nell'ambito del proprio dominio. Egli
controlla il dominio mediante il gruppo di protezione Domain Admins e altri gruppi di protezione incorporati. Nella tabella 7
sono riassunte le responsabilità e i compiti assegnati al proprietario di un dominio.
Tabella 7 Ruoli e responsabilità del proprietario di un dominio
Ambito di responsabilità
Compiti associati
Gestione delle operazioni dei domain controller
• Creazione e rimozione dei domain controller.
• Monitoraggio delle condizioni dei domain
controller.
• Gestione dei servizi in esecuzione nei domain
controller.
• Esecuzione di backup e ripristino.
Configurazione delle impostazioni del dominio
• Creazione dei criteri per il dominio e per gli
account utente di dominio, ad esempio
password, Kerberos e blocco degli account.
Delega dell'amministrazione al livello dei dati
• Creazione di unità organizzative e delega
dell'amministrazione.
• Risoluzione dei problemi della struttura delle
unità organizzative che i relativi proprietari non
sono in grado di risolvere a causa degli
insufficienti diritti di accesso.
Gestione delle relazioni di trust esterne
• Creazione di collegamenti di tipo trust con i
domini esterni alla foresta.
Attenzione Il livello di responsabilità richiesto ai proprietari dei domini ne esige l'attenta selezione, in quanto al proprietario di
un dominio spetta poi di controllare tutti gli utenti e i gruppi con compiti amministrativi.
Progettazione ottimale dei domini
La progettazione ottimale dei domini dipende dal numero di utenti della foresta e dalla larghezza di banda disponibile nella rete
per supportare la replica tra i domain controller. In tale progettazione è incluso quanto segue:
•
•
Un dominio radice dedicato gestito dal proprietario della foresta.
•
Tutti i domini sono in modalità nativa.
Uno o più domini di tipo geografico che fungono da domini figlio del dominio radice e che vengono gestiti dai
proprietari di dominio designati dal proprietario della foresta.
Nota Durante l'aggiornamento di un dominio da Windows NT a Windows 2000, alcuni domain controller continuano ad
eseguire Windows NT. Per utilizzare nella stessa rete sia domain controller Windows 2000 che Windows NT, è possibile
ricorrere alla modalità mista di Active Directory. In tale modalità alcune funzionalità di Active Directory vengono disattivate per
consentire l'interoperabilità con i Backup Domain Controller Windows NT (BDC). Quando dal dominio sono stati rimossi tutti i
BDC, è possibile passare alla modalità nativa e abilitare così le funzionalità seguenti di Windows 2000:
•
•
•
•
Gruppi universali
Nidificazione dei gruppi
Gruppi locali di dominio
Cronologia dei SID (SID History)
Tra queste funzionalità, i gruppi locali di dominio e la cronologia dei SID sono necessari per supportare la migrazione di utenti
e computer dai domini Windows NT.
Per beneficiare al massimo dei vantaggi offerti da Active Directory, è opportuno ridurre al minimo il numero di domini della
foresta. L'architettura ideale per la maggior parte delle organizzazioni è rappresentata da un dominio radice della foresta e da
un unico dominio figlio.
I componenti dell'architettura ottimale dei domini vengono descritti nella sezione che segue.
Dominio radice dedicato di una foresta
Al primo dominio creato in una foresta viene automaticamente assegnato il ruolo di dominio radice della foresta. Tutti gli altri
domini vengono aggiunti al dominio radice della foresta e contribuiscono a definire la gerarchia della directory. Nella radice
della foresta sono presenti i due gruppi amministrativi speciali il cui compito è di supportare l'infrastruttura di Active Directory:
Enterprise Admins e Schema Admins.
L'approccio ottimale alla progettazione dei domini prevede che il dominio radice della foresta sia dedicato esclusivamente
all'amministrazione dell'infrastruttura della foresta. I motivi per cui è consigliabile una radice dedicata sono esposti nella
tabella 8.
Tabella 8 Motivi per includere nella progettazione una radice dedicata
Motivo
Spiegazione
Le modifiche al livello di foresta possono essere
apportate da un numero minore di
amministratori
Limitando l'appartenenza al gruppo di
amministratori del dominio radice della foresta
viene ridotta la probabilità che un errore
amministrativo incida sull'intera foresta.
Può essere replicata facilmente per l'esecuzione
del backup della foresta
Un dominio radice di dimensioni ridotte può
essere replicato ovunque nella rete, così da
fornire la protezione necessaria contro eventi
catastrofici geograficamente circoscritti.
Non diventa mai obsoleta
Non è possibile eliminare il dominio radice,
neppure se l'organizzazione cambia. Un dominio
radice dedicato non diventa mai obsoleto perché
funziona solo come radice della foresta.
Proprietà trasferibile con facilità
Il trasferimento della proprietà del dominio
radice al fine di trasferire la proprietà della
foresta non comporta la migrazione dei dati di
produzione o delle risorse.
Il ruolo del dominio radice della foresta è rappresentato essenzialmente dalla definizione e dalla gestione dell'infrastruttura. La
gestione dell'infrastruttura della directory richiede nuove responsabilità e nuovi ruoli amministrativi. È necessario riservare il
dominio radice esclusivamente all'amministrazione della foresta, evitando di includere nel dominio radice della foresta risorse o
utenti non dedicati all'amministrazione della foresta.
Dominio figlio unico
In un dominio figlio unico del dominio radice della foresta sono inclusi tutti gli utenti, i computer e gli account di gruppo, ad
eccezione di quelli degli amministratori della directory residenti nella radice della foresta. Nella figura 9 viene illustrata una
foresta con un unico dominio figlio.
Figura 9 Foresta con un dominio radice e un unico dominio figlio
Domini di tipo geografico
Tutti i dati degli oggetti di un dominio vengono replicati per intero in tutti i domain controller in esso inclusi. Per questo motivo
può rivelarsi necessario configurare un gruppo di domini figlio di tipo geografico qualora la foresta contenga numerosi utenti
sparsi in località con connessioni WAN lente. Se l'organizzazione non è in grado di supportare un'architettura costituita da un
unico dominio figlio, la soluzione ottimale è rappresentata dai domini di tipo geografico poiché essi:
•
•
•
Possono essere distribuiti in modo coerente con la connettività WAN.
Possono rispondere al meglio alle esigenze IT di un'organizzazione tipica.
Si basano su una struttura organizzativa stabile.
Nota In alcune organizzazioni, le divisioni sono state sviluppate come unità autonome in termini di infrastrutture IT e pertanto
non coordinano i propri servizi con quelli di alcun'altra divisione.
Il proprietario di una foresta, che in ultima analisi è responsabile della fornitura dei servizi, generalmente non delega volentieri
la responsabilità dei servizi di directory a un amministratore IT di una divisione autonoma. Inoltre, per motivi di sicurezza è
consigliabile che tutti i proprietari dei domini di una foresta condivisa si considerino reciprocamente affidabili. L'amministratore
IT di una divisione autonoma desidera con ogni probabilità mantenere una certa indipendenza. Per poter mantenere questo
livello di autonomia egli deve obbligatoriamente creare una foresta distinta. Per questi motivi i domini basati sulla struttura
organizzativa non possono essere ritenuti una soluzione ottimale.
Nella figura 10 viene illustrata una foresta con domini di tipo geografico.
Figura 10 Foresta con una radice dedicata e tre domini figlio
Processo di progettazione dei domini
Durante la progettazione di un dominio è necessario valutare l'ambiente IT esistente e l'architettura amministrativa corrente
per poter determinare il modo migliore per trasformare i domini Windows NT correnti nel minor numero possibile di domini
Active Directory. È opportuno specificare quanto segue:
1.
2.
3.
4.
Il numero di domini Active Directory dell'architettura.
L'ambito di ogni nuovo dominio Active Directory.
Il nome di ogni dominio.
Se ogni dominio Active Directory viene creato o aggiornato da Windows NT.
Il processo di progettazione ottimale dei domini, include i passaggi seguenti:
1.
2.
3.
4.
5.
Progettare il dominio radice dedicato della foresta.
Scegliere tra un modello di domini “regionali” e un unico dominio globale.
Se un unico dominio globale risulta insufficiente, dividere l'organizzazione globale in domini regionali.
Per ogni dominio specificare se si eseguirà l'aggiornamento di un dominio Windows NT esistente o se verrà creato un
nuovo dominio.
Far corrispondere tutti i domini restanti a uno dei domini regionali per eseguirne il consolidamento.
Nella figura 11 vengono illustrati i compiti connessi alla progettazione dei domini.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 11 Compiti inclusi nel processo di progettazione dei domini
Progettazione del dominio radice della foresta
La progettazione del dominio radice della foresta implica la necessità di assegnargli un nome. Ai domini Active Directory
possono essere assegnati due tipi di nomi:
•
•
I nomi DNS (Domain Name System), utilizzati dai client Windows 2000.
I nomi NetBIOS, utilizzati dai client che eseguono versioni precedenti di Windows.
Il nome del dominio radice della foresta è anche il nome della foresta. Per assegnare un nome al dominio radice della foresta:
1.
Identificare il proprietario DNS dell'organizzazione e determinare quali sono i nomi DNS registrati disponibili nella
rete che ospiterà Active Directory.
È possibile che i nomi disponibili in tale rete siano diversi da quelli utilizzati dall'azienda su Internet. Ad esempio, il
nome utilizzato dall'organizzazione su Internet potrebbe essere contosopharma.com, mentre quello utilizzato nella
rete aziendale interna potrebbe essere contoso.com. In questo caso il nome da scegliere sarà contoso.com.
Se non è registrato alcun nome di dominio, è necessario registrarne uno presso un'autorità di registrazione DNS
Internet.
Nota È preferibile utilizzare nomi DNS registrati presso un'autorità Internet nello spazio dei nomi Active Directory.
L'univocità globale dei nomi è garantita solo per quelli registrati. Se un'altra organizzazione registra in seguito lo
stesso nome di dominio DNS oppure se l'organizzazione si fonde con un'altra, acquisisce un'azienda o viene acquisita
da una società che utilizza gli stessi nomi DNS, le due infrastrutture non potranno mai interagire reciprocamente.
Per creare un nuovo nome subordinato, aggiungere al nome DNS registrato un prefisso attualmente non utilizzato.
Ad esempio, se il nome DNS della radice fosse contoso.com, sarebbe necessario creare un nome di dominio per la
radice della foresta Active Directory (quale concorp.contoso.com), purché lo spazio dei nomi concorp.contoso.com
non sia ancora utilizzato nella rete. Il nuovo ramo dello spazio dei nomi verrà dedicato ad Active Directory e a
Windows 2000, e potrà essere facilmente integrato con l'implementazione DNS esistente. Le regole per la scelta del
prefisso sono indicate nella tabella 9.
Tabella 9 Regole per la creazione di un prefisso per un nome Active Directory
2.
Regola per il prefisso
Spiegazione
Improbabile che diventi obsoleto
I domini non possono essere rinominati, pertanto
è consigliabile evitare nomi, quali una linea di
prodotti o un sistema operativo, che potrebbero
diventare obsoleti. Si consiglia l'utilizzo di nomi
geografici.
Solo caratteri standard Internet
A-Z, a-z, 0-9 e (-), ma non nomi formati
unicamente da cifre.
Al massimo 15 caratteri
Se si sceglie un prefisso la cui lunghezza
massima è di 15 caratteri, il nome NetBIOS
utilizzato dai client di livello inferiore potrà
essere uguale al prefisso.
Concordare con il proprietario DNS la delega della proprietà di tale nome.
Nella sezione di questo documento concernente la progettazione del servizio DNS vengono descritti in maggiore
dettaglio i nomi DNS e la pianificazione del deployment del sistema DNS.
Scelta tra un modello basato su domini regionali e un unico dominio globale
Stabilire se l'architettura desiderata debba basarsi su un modello con più domini di tipo geografico o su un solo dominio
globale. È consigliabile preferire un modello con un unico dominio globale per i motivi seguenti:
•
•
•
Non è mai necessario spostare gli utenti da un dominio all'altro.
Non è necessario duplicare in più domini le impostazioni dei criteri di gruppo.
L'autenticazione di un utente può essere eseguita da qualsiasi domain controller.
In alcune organizzazioni di grandi dimensioni, un collegamento di rete lento con un domain controller può non essere in grado
di gestire il traffico di replica di un unico dominio globale. In tal caso, è opportuno scegliere il modello a domini regionali. Fare
riferimento alla tabella 10 per stabilire il numero massimo di utenti che un unico dominio globale è in grado di supportare.
Prendere in considerazione la crescita dell'organizzazione nell'applicare queste linee guida.
Tabella 10 Linee guide per il dimensionamento della replica in un unico dominio globale
Collegamento più lento con un domain
controller (kbps):
Creare un unico dominio globale con un
numero di utenti non superiore a:
9,6
20.000
14,4
30.000
19,2
40.000
28,8
50.000
38,4
75.000
56 o velocità superiore
100.000
Nota Le stime riportate riguardano foreste con un numero massimo di 100.000 utenti. Benché possibili, foreste di maggiori
dimensioni non sono prese in considerazione in queste linee guida. I valori indicati esprimono stime per difetto. Viene
presupposto quanto segue:
•
•
•
•
•
•
•
•
Per la gestione della replica è disponibile il 10% della larghezza di banda minima.
Tutti i domain controller (DC) sono server per la gestione del catalogo globale.
La percentuale di inserimento di nuovi utenti all'anno è del 20%.
La percentuale di utenti che vengono eliminati ogni anno è del 15%.
Le modifiche dell'appartenenza a un gruppo rappresentano un fattore fondamentale del carico di lavoro della replica.
Esiste un rapporto 1:1 tra utenti e computer.
Il sistema DNS è integrato con il servizio di directory.
Viene utilizzata la funzionalità di scavenging (pulizia) del servizio DNS.
Conviene utilizzare questo elenco unicamente come riferimento. Prima di implementare il piano dei domini, verificare che la
rete sia in grado di gestire il traffico di replica eseguendo appositi test di laboratorio. Per ulteriori informazioni sul
dimensionamento dei domini, consultare Building Enterprise Active Directory Services: Notes From the Field di Microsoft
Consulting Services, 2000, Redmond, Microsoft Press.
Se esistono più domini Windows NT, questi dovranno essere migrati nel nuovo dominio globale Active Directory. Se, tuttavia, i
domini MUD sono già stati consolidati in meno di dieci domini di tipo geografico, potrebbe darsi il caso che in seguito si
desideri aggiornarli anziché eseguire la migrazione degli utenti in un unico dominio globale. Lo spostamento degli account da
un dominio all'altro può avere impatto sugli utenti finali. Prima di prendere una decisione, è opportuno valutare i vantaggi
amministrativi a lungo termine derivanti dall'adozione di un dominio globale rispetto al costo in cui si incorre per eseguire la
migrazione degli utenti. Questa valutazione viene descritta nella sezione seguente "Suddivisione dell'organizzazione globale in
domini regionali".
Suddivisione dell'organizzazione globale in domini regionali
Se per limiti di dimensioni è opportuno dividere la foresta in domini regionali, è necessario:
1.
Ripartire l'organizzazione in regioni in base a un elemento significativo, ad esempio:
o Continente
o Connettività di rete
o Regione amministrativa
Per ogni regione verrà creato un dominio Active Directory. Lo scopo è di ridurre al minimo il numero di domini da
creare. Pertanto è consigliabile pianificare non più di dieci domini. Quando si intende aggiungere domini alla foresta,
è opportuno rammentare che l'incremento del numero di domini dovrebbe rappresentare un compromesso tra
l'ottimizzazione della larghezza di banda per la replica e la riduzione dei costi amministrativi, descritti nella tabella
11.
Tabella 11 Sforzo gestionale associato all'aggiunta di domini a una foresta
Sforzo richiesto
Implicazioni
Gestione di più gruppi Domain Admins
Dato che gli amministratori di dominio hanno un
controllo completo dei rispettivi domini, è
necessario controllare con attenzione
l'appartenenza al gruppo degli amministratori di
dominio. Ad ogni dominio aggiunto a una foresta
consegue un aumento del carico gestionale.
Hardware degli ulteriori domain controller
Un domain controller può ospitare un solo
dominio. Ogni nuovo dominio richiede almeno
due computer per poter soddisfare i requisiti di
affidabilità e disponibilità. Poiché tutti i domain
controller possono accettare e originare
modifiche, è necessario proteggerli fisicamente.
Relazioni di trust
Affinché un utente di un dominio possa accedere
a una risorsa di un altro dominio, è necessario
che i due domain controller entrino in contatto.
Questa comunicazione rappresenta un ulteriore
rischio di errore. Minore è il numero di domini,
meno gli utenti dovranno ricorrere a
comunicazioni con più domain controller per
usufruire dei servizi.
2.
Criteri di gruppo e gestione del controllo
dell'accesso comuni a più domini
I criteri di gruppo e il controllo dell'accesso validi
in un dominio non lo sono automaticamente
anche in altri domini. Se i criteri di gruppo sono
stati impostati o l'amministrazione è stata
delegata mediante un controllo dell'accesso che
sia uniforme in più domini, è necessario applicarli
separatamente a ogni dominio.
Maggiore probabilità di dover spostare gli oggetti
da un dominio all'altro
La facilità di eseguire una ristrutturazione
all'interno di un dominio consiglia di preferire un
numero ridotto di domini stabili e di grandi
dimensioni. Con l'aggiunta di domini aumenta la
probabilità di dover spostare un oggetto, ad
esempio un utente, o un gruppo di oggetti da un
dominio a un altro. Lo spostamento di un utente
all'interno di un dominio è semplice, mentre
spostarlo da un dominio all'altro può incidere
negativamente su di esso.
Per ogni regione utilizzare la tabella 12 per stabilire se vengono rispettate le linee guida relative al dimensionamento,
quindi:
1. Individuare il collegamento di rete più lento tra i domain controller, inclusi i collegamenti tra la regione e le
altre regioni.
2. Individuare la riga del grafico corrispondente al collegamento più lento (arrotondare per difetto).
3. Se il numero di utenti della regione eccede quello consigliato, suddividere la regione in regioni più piccole.
Prendere in considerazione la crescita dell'organizzazione nell'applicare queste linee guida.
Tabella 12 Linee guide per il dimensionamento della replica per i domini regionali
3.
Larghezza di banda minima
(kbps)
Creare una foresta con un
numero di utenti non
superiore a:
Creare un dominio regionale
con un numero di utenti non
superiore a:
9,6
25.000
15.000
14,4
50.000
15.000
19,2
50.000
25.000
28,8
75.000
40.000
38,4
100.000
45.000
56 o velocità superiore
100.000
100.000
Nota Le stime riportate riguardano foreste con un numero massimo di 100.000 utenti. Benché possibili, foreste di
maggiori dimensioni non sono prese in considerazione in queste linee guida. I valori indicati esprimono stime per
difetto. Viene presupposto quanto segue:
o Per la gestione della replica è disponibile il 10% della larghezza di banda minima.
o Tutti i domain controller (DC) sono server per la gestione del catalogo globale.
o La percentuale di inserimento di nuovi utenti all'anno è del 20%.
o La percentuale di utenti che vengono eliminati ogni anno è del 15%.
o Le modifiche dell'appartenenza a un gruppo rappresentano un fattore fondamentale del carico di lavoro
della replica.
o C’è un Esiste un rapporto 1:1 tra utenti e computer.
o Il sistema DNS è integrato con il servizio di directory.
o Viene utilizzata la funzionalità di scavenging (pulizia) del servizio DNS.
Conviene Conviene utilizzare questo elenco unicamente come riferimento. Prima di implementare il piano dei domini,
verificare che la rete sia in grado di gestire il traffico di replica eseguendo appositi test di laboratorio. Per ulteriori
informazioni sul dimensionamento dei domini, consultare Building Enterprise Active Directory Services: Notes From
the Field di Microsoft Consulting Services, 2000, Redmond, Microsoft Press.
4.
Se in un dominio esistono più di 50.000 utenti, specificare un PDC dedicato.
Il PDC dedicato va configurato unicamente per gestire le operazioni PDC. In Best Practices Active Directory
Deployment for Managing Windows Networks viene descritto in maggiore dettaglio come configurare un PDC
dedicato.
Nella figura 12 viene illustrata un'architettura di domini regionali. In questo esempio la foresta include 60.000 utenti. Essendo
la larghezza minima di banda di 32 kbps, in base alle linee guida fornite è consigliabile includere in un dominio non più di
50.000 utenti. In questo caso è opportuno implementare un'architettura con tre domini che rispecchino le divisioni
geografiche. I domini, sempre in base alle linee guida relative alla replica tra domini, dovrebbero includere 40.000, 15.000 e
5.000 utenti.
Figura 12 Distribuzione regionale degli utenti e dei computer di un'organizzazione
Definizione di un dominio nuovo o scelta di uno aggiornato per ogni regione
Ogni regione rappresenta un dominio Active Directory. Tali domini possono derivare dalla creazione di un nuovo dominio vuoto
in cui eseguire la migrazione di utenti e computer oppure dall'aggiornamento di un dominio Windows NT esistente. Se si
esegue l'aggiornamento da Windows NT, è probabile che esistano già diversi domini MUD.
Attenersi alla procedura seguente per specificare per ogni regione un dominio nuovo o aggiornato.
1.
Se si esegue la migrazione da Windows NT, esaminare ogni dominio MUD della regione e stabilire se ve ne siano
alcuni che possano essere aggiornati per diventare domini regionali.
Per ulteriori informazioni sull'argomento, vedere la sezione seguente "Valutazione dei domini MUD attuali di una
regione".
2.
Se si esegue la migrazione da un sistema operativo diverso da Windows NT oppure se non vi sono domini MUD di
Windows NT aggiornabili, creare un nuovo dominio regionale.
Per ulteriori informazioni sull'argomento, vedere la sezione "Progettazione di nuovi domini regionali".
Valutazione dei domini MUD attuali di una regione
Importante Le informazioni incluse in questa sezione concernono le organizzazioni che eseguono la migrazione da Windows
NT. Se si utilizza un altro sistema operativo, è possibile passare alla sezione successiva.
Prima di eseguire la migrazione da Windows NT, gli utenti e le risorse risiedono nei domini Windows NT. In questa fase della
progettazione il proprietario della foresta determina il modo migliore per eseguire la migrazione di tali domini Windows NT e
per consolidarli nell'architettura Active Directory finale.
Prima di iniziare, è necessario creare l'elenco dei domini MUD della regione che verranno inseriti nella foresta. Per ognuno di
tali domini MUD compilare un foglio di lavoro. Per ogni dominio MUD sarà necessario decidere se si desidera:
•
•
Aggiornare il MUD, ovvero aggiornare a Windows 2000 Active Directory tutti i domain controller del dominio MUD.
Eliminare il dominio MUD e migrarne gli account utente in un dominio nuovo o aggiornato.
Nella tabella 13 vengono fornite informazioni grazie alle quali poter stabilire se aggiornare un dominio MUD oppure migrarne il
contenuto.
Tabella 13 Motivi a favore e contro l'aggiornamento di un dominio MUD
Aggiornare perché
• Il dominio corrente è adeguato al modello
regionale.
• Operazione più veloce rispetto alla migrazione
degli utenti in un nuovo dominio.
Creare un nuovo dominio ed eseguire la
migrazione perché
• Il dominio riguarda più regioni e il contenuto
deve essere ripartito tra diversi domini
regionali.
• È necessario troppo tempo per aggiornare il
dominio alla modalità nativa (aggiornamento
di tutti i domain controller).
Importante Tenere presente che se si sceglie di aggiornare un dominio Windows NT a dominio regionale, questo non potrà
fungere da dominio di destinazione per il consolidamento dei domini fino a quando non sarà in modalità nativa. Il passaggio
alla modalità nativa di Active Directory potrebbe richiedere più tempo del previsto se nelle sedi lontane sono presenti molti
BDC o se questi ultimi necessitano di aggiornamenti hardware. In questo caso è possibile scegliere un altro dominio Windows
NT da aggiornare oppure creare un nuovo dominio come destinazione del consolidamento.
È preferibile aggiornare a Windows 2000 un solo dominio MUD per regione. Tuttavia, può accadere che non sia presente alcun
dominio MUD adatto all'aggiornamento oppure che ne vengano identificati più di uno. Nel primo caso, è possibile creare un
nuovo dominio. Questa operazione viene descritta nella prossima sezione.
Se invece vengono identificati più domini MUD adatti all'aggiornamento, è possibile:
•
•
Aggiornare il dominio MUD più grande e consolidarvi i restanti domini MUD.
Definire ulteriori regioni e aggiornare ogni dominio MUD alla modalità nativa.
Se si decide di definire ulteriori regioni, è opportuno rammentare di prendere in considerazione l'ulteriore sforzo
gestionale associato all'aggiunta di domini alla foresta.
Per ogni dominio che il proprietario della foresta sceglie di aggiornare alla modalità nativa nel contesto dell'architettura Active
Directory:
1.
Assegnare un nome DNS al dominio.
Assegnare <prefisso_dominio>.<nome foresta> come nome del dominio. Per impostazione predefinita, Windows
2000 utilizza il nome NetBIOS corrente come prefisso del dominio. È possibile modificare tale prefisso durante
l'aggiornamento, sebbene sia consigliabile conservarlo. In tal modo si garantisce la visualizzazione dello stesso nome
quando il nome del dominio viene visualizzato in Windows 2000 o in versioni precedenti del sistema operativo.
2.
3.
Assegnare a qualcuno il ruolo di proprietario del nuovo dominio.
Assicurarsi che l'attuale proprietario del dominio sia d'accordo.
Progettazione di nuovi domini regionali
Nell'ambito della progettazione dei domini, il proprietario della foresta deve creare nuovi domini se:
•
•
L'organizzazione non dispone attualmente di domini Windows NT.
Nessuno dei domini esistenti è adatto ad essere aggiornato.
Dopo aver specificato nuovi domini regionali, distribuirvi gli account e le risorse.
Per ogni nuovo dominio che il proprietario della foresta sceglie di aggiungere all'architettura Windows 2000:
1.
Assegnare un nome DNS al dominio.
Utilizzare <nuovo nome>.<nome foresta> come nome del dominio. Le regole per la scelta del prefisso sono indicate
nella tabella 9.
2.
Assegnare a qualcuno il ruolo di proprietario del nuovo dominio.
Esempio di definizione di domini nuovi o aggiornati
L'architettura di domini presentata nella figura 13 richiede l'aggiornamento alla modalità nativa dei due domini MUD delle
regioni nordamericana e sudamericana, in modo che diventino domini regionali di Windows 2000. In Europa entrambi i domini
MUD hanno numerosi domain controller in località remote. Il proprietario della foresta ha stabilito che in entrambi i casi
l'aggiornamento alla modalità nativa richiederebbe troppo tempo. Pertanto, è stata preferita la creazione di un nuovo dominio.
I tre domini MUD rimanenti verranno consolidati nel dominio regionale delle rispettive zone.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 13 Creazione di domini Active Directory mediante l'aggiornamento dei domini MUD di Windows NT
(triangolo con un cerchio) o mediante la creazione di un nuovo dominio (solo triangolo)
Consolidamento dei domini dedicati agli account Windows NT rimanenti
È necessario consolidare tutti i domini MUD restanti nei rispettivi domini regionali. Quando si consolida un dominio MUD in un
altro dominio, è opportuno ricordare che:
•
È possibile configurare le unità organizzative in modo da conservare l'organizzazione e l'amministrazione dei domini
originali.
La progettazione delle unità organizzative viene trattata in una successiva sezione della presente guida.
•
Il processo di consolidamento incide sugli utenti che vengono migrati.
Il processo di migrazione degli utenti viene descritto in dettaglio nella guida complementare Best Practice Active
Directory Deployment for Managing Windows Networks.
Nota Se si prevede di suddividere il contenuto di un dominio Windows NT in più domini regionali, la procedura ottimale è
rappresentata dalla migrazione di tale contenuto in altri domini di destinazione e non dall'aggiornamento del dominio con
successivo passaggio alla modalità nativa.
Nella figura 14 viene illustrato il modo in cui tutti i domini MUD di Windows NT restanti vengono consolidati nei domini
regionali Active Directory di concorp.contoso.com.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 14 Consolidamento dei domini MUD di Windows NT nei domini Active Directory
Consolidamento dei domini di risorse Windows NT
In una pianificazione ottimale è necessario prevedere il consolidamento di tutti i domini di risorse Windows NT nel dominio
Active Directory della rispettiva regione.
Determinare il dominio in cui spostare il contenuto del dominio di risorse è spesso semplice. Dato che gli utenti desiderano i
dati il più vicino possibile, la maggior parte dei domini di risorse è organizzata geograficamente in modo da corrispondere agli
utenti di una particolare località. Pertanto, quasi tutti i domini di risorse possono essere prontamente consolidati nei domini
Active Directory che includono account utente della località. Nei casi in cui il contenuto del dominio di risorse Windows NT
abbracci più aree geografiche, specificare di quali risorse eseguire la migrazione e in quali domini di destinazione. È opportuno
rammentare che, quando si consolida un dominio MUD in un dominio Windows 2000 di destinazione, è possibile configurare
unità organizzative in modo da conservare l'organizzazione e l'amministrazione del dominio originale.
Negli altri casi, è possibile conservare il dominio di risorse Windows NT fino a quando non lo si consolidi o lo si elimini perché
obsoleto. Questa evenienza può verificarsi se nei domain controller del dominio vengono eseguite applicazioni incompatibili con
Windows 2000.
Nota Se un dominio di risorse è dedicato a Exchange 5.5, è opportuno lasciare che per il momento vi venga eseguito Windows
NT. Per pianificare la migrazione di Exchange, vedere Microsoft Exchange 2000 Server Upgrade Series, disponibile on-line
all'indirizzo http://www.microsoft.com/technet/itsolutions/guide/default.asp.
Nella figura 15 viene illustrato il modo in cui il proprietario della foresta può scegliere di consolidare i domini di risorse esistenti
in domini Active Directory della stessa regione.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 15 Consolidamento dei domini di risorse Windows NT in domini Windows 2000
In questo scenario tutti i domini di risorse sono stati organizzati su base regionale. In questo modo è stato facile stabilire in
quale punto della gerarchia dei domini regionali consolidare ogni dominio di risorse.
Nella figura 16 viene illustrata la struttura finale della foresta Active Directory di concorp.contoso.com. Essa è costituita da un
dominio radice e da tre domini regionali.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 16 Struttura finale dei domini Active Directory di concorp.contoso.com
Il passaggio successivo
Nel corso del processo di progettazione dei domini, ogni proprietario della foresta ha specificato un nome di dominio per la
radice della foresta e la struttura logica di Active Directory. Dal momento che Active Directory si avvale del sistema DNS per la
risoluzione dei nomi, il passaggio successivo che il proprietario della foresta deve eseguire è rappresentato dalla nomina di un
proprietario del servizio DNS per Active Directory e dalla specificazione della struttura di tale servizio DNS.
Se l'organizzazione ha già implementato un servizio DNS, il proprietario della foresta e il proprietario del servizio DNS per
Active Directory collaborano con il proprietario del servizio DNS attuale per delegare il nome DNS della radice della foresta ad
Active Directory. Se il servizio DNS non è stato implementato, il proprietario della foresta e il proprietario del servizio DNS per
Active Directory devono pianificarne l'implementazione.
Nella sezione seguente viene descritto in dettaglio tale processo.
Creazione di una struttura DNS per Active Directory
Per il proprietario della foresta e per gli amministratori Windows NT il concetto di servizio DNS può risultare nuovo. Il servizio
DNS consente la trasformazione dei nomi in indirizzi IP. Le periferiche di rete utilizzano gli indirizzi IP per individuare gli host e
collegarsi ad essi. Tuttavia, gli utenti trovano difficile ricordare gli indirizzi IP e di solito preferiscono i nomi, come ad esempio
ftp.contoso.com. Il servizio DNS consente agli utenti di immettere nomi gerarchici e facili da ricordare per connettersi ai
computer e alle altre risorse delle reti IP.
Il servizio DNS rappresenta per Windows 2000 un sostituto a lungo termine, con migliore scalabilità del sistema di risoluzione
dei nomi NetBIOS, che viene fornito dal servizio WINS (Windows Internet Name Service) nelle reti Windows NT. È tuttavia
ancora necessario prevedere il servizio WINS per supportare i client che eseguono versioni di Windows precedenti a Windows
2000, in quanto tali client non sanno come utilizzare il servizio DNS per individuare i domini.
In questo documento viene spiegato come creare una struttura in base alle scelte fatte nella precedente sezione
"Pianificazione dei domini". La presente guida include le procedure ottimali per progettare un servizio DNS per Active Directory
in una rete con:
•
•
Nessun servizio DNS
Un servizio DNS già in uso
Ruolo del servizio DNS nelle architetture delle reti Windows
Per comprendere in quale modo Windows 2000 e Active Directory utilizzano il servizio DNS, è importante capire cosa è e come
funziona tale servizio.
Il servizio DNS è un database distribuito che include tutte le informazioni necessarie affinché un qualsiasi client possa ricercare
un qualsiasi nome. Il database è una struttura gerarchica sotto forma di albero al contrario. Tale albero è noto anche come
spazio dei nomi. Internet rappresenta un tipo di spazio dei nomi. Qualsiasi client che si trovi nello spazio dei nomi Internet può
ricercarvi un nome. Alcune aziende hanno anche uno spazio dei nomi interno o privato.
Il servizio DNS è stato ideato in modo che qualsiasi server DNS possa rispondere alle richieste concernenti qualsiasi nome
facente parte del suo spazio dei nomi. Un server DNS può rispondere in tre modi:
•
•
Se la risposta si trova nella cache, la preleva da quella.
Se la risposta si trova in una zona ospitata dal server DNS, la preleva da quella zona.
Per zona si intende una parte dell'albero DNS contenente tutti i record necessari per rispondere alle richieste
concernenti i nomi in essa contenuti. Quando un server DNS ospita una zona, è ritenuto autorevole per tale zona e
può rispondere alle richieste concernenti qualsiasi nome della zona. Ad esempio, un server che ospita la zona
contoso.com ha l’autorità per rispondere alle richieste riguardanti qualsiasi nome di tale zona.
•
Se un server non può rispondere ricorrendo ai dati inclusi nella cache o nelle zone, inoltra la richiesta ad altri server.
Affinché un server radice DNS sia in grado di rispondere alle richieste concernenti un nome, deve disporre di un percorso
diretto o indiretto per raggiungere tutti i server e le zone dello spazio dei nomi. Nella figura 17 viene illustrato come il server
radice DNS contatta gli altri server dello spazio dei nomi.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 17 Esempio di delega
Il server radice DNS ospita la zona radice, rappresentata da un punto ( . ). La zona radice include una delega a una zona del
successivo livello della gerarchia, la zona com. Per delega si intende un record nella zona padre che indica il nome del server
che ha autorità per la zona delegata. In questo esempio, il nome del server autorevole è Server.com. La delega presente nella
zona radice segnala al server radice DNS che, per trovare la zona com, deve contattare Server.com. Analogamente, la delega
presente nella zona com segnala a Server.com che, per trovare la zona contoso.com, deve contattare Server.contoso.com.
Nota La delega utilizza due tipi di record. Il record relativo alla risorsa NS (Name Server) indica il nome del server a cui fare
riferimento. Il record relativo alla risorsa A (Host) indica, invece, l'indirizzo IP del server stesso.
In questo modo, il server radice DNS può individuare qualsiasi nome dello spazio dei nomi. La zona radice include deleghe che
conducono direttamente o indirettamente a tutte le altre zone. I server in grado di inviare query al server radice DNS possono
utilizzare le informazioni incluse nelle deleghe per trovare qualsiasi nome dello spazio dei nomi. I server DNS includono i
percorsi predefiniti (Root Hints), ovvero un elenco di nomi e di indirizzi IP, che segnala loro in quale modo inviare richieste ai
server radice DNS.
Alcuni server di certe configurazioni non includono i percorsi predefiniti. Essi inoltrano a un altro server tutte le richieste a cui
non sono in grado di rispondere.
Risoluzione ricorsiva dei nomi
I client dipendono dai server DNS per rispondere a tutte le richieste di risoluzione dei nomi. In un processo detto risoluzione
ricorsiva dei nomi i client utilizzano una query ricorsiva per chiedere ai server di risolvere i nomi e specificare che il server
deve fornire una risposta definitiva, a prescindere dall'esistenza del nome. Se un server non è in grado di rispondere in modo
affidabile, invia la query a un altro server DNS. Il server DNS stabilisce a quale server inviare la query in due modi diversi:
utilizzando i percorsi predefiniti o inoltrando la query.
Risoluzione dei nomi mediante i percorsi predefiniti (Root Hints)
Nella figura 18 viene illustrato il modo in cui il server DNS risolve un nome utilizzando i percorsi predefiniti.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 18 Esempio di risoluzione ricorsiva dei nomi mediante i percorsi predefiniti
In questo esempio, (1) un client invia una query ricorsiva a un server DNS concernente il nome ftp.contoso.com. Dal momento
che il servizio DNS non ha autorità in riferimento a tale nome e non dispone della risposta nella propria cache, il server DNS
controlla i propri percorsi predefiniti al fine di individuare l'indirizzo IP del server radice DNS. Quindi (2) utilizza una query
iterativa per chiedere al server radice DNS di risolvere il nome ftp.contoso.com. Utilizzando una query iterativa il server non
chiede necessariamente una risposta definitiva. Piuttosto, esso accetta un puntatore a un altro server che potrebbe avere una
risposta più corretta. Poiché il nome ftp.contoso.com termina con il suffisso com, (3) il server radice DNS restituisce una
delega alla zona com. Il server DNS continua quindi (4, 5) a inviare query iterative fino a quando (6) non raggiunge
Server.contoso.com, che trova la risposta nei file della propria zona e (7) risponde con una risposta definitiva. (8) Il server
restituisce infine il risultato al client.
Risoluzione dei nomi mediante inoltro (Forwarding)
L'inoltro consente di indirizzare la risoluzione dei nomi attraverso determinati server anziché mediante l'utilizzo dei percorsi
predefiniti. Si tratta di una scelta amministrativa non necessariamente a supporto di Active Directory. Se è già presente un
servizio DNS, tale scelta è già stata fatta. Nella figura 19 viene illustrato un esempio di query inoltrata.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 19 Esempio di inoltro
Questo esempio è analogo al precedente, tranne che il client invia la richiesta a un server configurato per l'inoltro delle query.
Quando (1) il client invia una richiesta concernente il nome client.contoso.com, (2) il server che la riceve la inoltra a un altro
server, noto come server d'inoltro. I passaggi successivi sono gli stessi della figura precedente.
Ricerche dirette e inverse
Se un client chiede a un server l'indirizzo IP corrispondente a un determinato nome, richiede a tale server l'esecuzione di una
ricerca diretta. La risposta si trova in una zona di ricerca diretta (forward lookup zone).
D'altro canto, se un client chiede a un server il nome corrispondente a un determinato indirizzo IP, richiede a tale server
l'esecuzione di una ricerca inversa. La risposta si trova in una zona di ricerca inversa (reverse lookup zone). Gli indirizzi IP dei
computer sono memorizzati in record detti record puntatori (PTR).
La capacità di eseguire ricerche inverse non è necessaria per il corretto funzionamento di Active Directory. Se esiste già uno
spazio dei nomi DNS con zone di ricerca inversa, l'amministratore del sistema DNS esistente può continuare a gestire tali zone.
Se invece non esiste alcuno spazio dei nomi DNS, non è necessario creare zone di ricerca inversa al fine di eseguire il
deployment di Active Directory.
Individuazione dei domain controller Active Directory
I client comunicano con i domain controller per l'esecuzione di operazioni quali l'elaborazione delle richieste di accesso e le
ricerche delle risorse pubblicate nella directory, ad esempio le stampanti. Nella figura 20 viene illustrato il modo in cui i client
utilizzano il servizio DNS per individuare i domain controller Active Directory. In questo esempio, (1) il domain controller viene
registrato nel sistema DNS. Il client invia (2) a un server DNS una query concernente i nomi dei domain controller del dominio.
Il server DNS esegue la risoluzione ricorsiva dei nomi al fine di trovare i nomi dei domain controller, quindi restituisce tali nomi
e gli indirizzi IP al client. Il client (3) utilizza l'indirizzo IP per contattare il domain controller.
Figura 20 Come i client individuano i domain controller
I client necessitano dell'indirizzo IP di un server DNS per poter individuare un domain controller. I domain controller registrano
diversi record nel sistema DNS per facilitarne l'individuazione da parte dei client e degli altri computer. Tali record sono detti
record di individuazione.
Sistema DNS integrato in Windows 2000 Active Directory
Il server DNS di Windows 2000 è in grado di memorizzare le proprie zone in Active Directory. L'integrazione con Active
Directory presenta i vantaggi seguenti:
•
Crea più master per la replica DNS, pertanto:
o Qualsiasi server DNS è in grado di accettare gli aggiornamenti relativi a tale zona.
o Non richiede alcuno studio per una topologia distinta per la replica DNS.
•
Supporta gli aggiornamenti dinamici protetti.
Gli aggiornamenti dinamici protetti consentono agli amministratori di controllare in modo rigoroso quali computer
eseguono l'aggiornamento e quali sono i nomi che vengono aggiornati. Essi inoltre impediscono ai computer non
autorizzati di sovrascrivere i nomi esistenti del sistema DNS.
•
Supporta lo scavenging (pulizia) dei record obsoleti.
Per ulteriori informazioni sul sistema DNS, consultare una delle risorse elencate nella tabella 14.
Tabella 14 Ulteriori informazioni sul sistema DNS
Informazioni generali sul
sistema DNS
Risorsa
"Introduction to DNS" in TCP/IP
Core Networking Guide di
Windows 2000 Server Resource
Kit
Informazioni sul sistema
DNS di Windows 2000
•
•
"Windows 2000 DNS" in
Networking Guide di Windows
2000 Server Resource Kit
DNS and BIND, 3a edizione, di
Paul Albitz e Cricket Liu, 1998,
Sebastopol, CA, O'Reilly &
Associates
•
RFC 1034 e 1035.
•
Guida in linea di Windows 2000
Server.
•
•
Per ulteriori informazioni sui documenti RFC 1034 e 1035, vedere il collegamento "Request for Comments" della pagina "Web
Resources" all'indirizzo http://www.microsoft.com/windows2000/techinfo/reskit/WebResources/default.asp.
Denominazione dei computer
In Windows 2000 è stato introdotto il concetto di suffisso DNS primario di un nome di computer. Quando un computer
Windows 2000 viene unito a un dominio, si registra per impostazione predefinita con un nome costituito dal nome host del
computer e dal nome DNS del dominio del quale il computer è entrato a fare parte (<nome_computer>.<suffisso_primario>).
Il nome DNS completo del computer è noto come nome primario.
Un computer può già avere un nome DNS immesso staticamente in un server DNS o registrato da un servizio DNS/DHCP
integrato. Il nome primario del computer è comunque tenuto distinto da quelli registrati in precedenza.
Elementi della progettazione del sistema DNS
Il proprietario della foresta e il proprietario del servizio DNS sono responsabili del completamento della progettazione del
sistema DNS per conto della propria organizzazione. Nel piano è necessario prevedere:
•
•
Configurazione del server DNS che include:
o Posizionamento del server DNS.
o Tipo e posizionamento delle zone.
o Metodo ricorsivo per la risoluzione dei nomi.
Configurazione del client DNS che include:
o Schema di denominazione dei computer.
o Configurazione del resolver.
Ruolo del proprietario del servizio DNS
Per ogni dominio deve esistere un proprietario DNS, che dipende dal proprietario del dominio. Il proprietario DNS è
responsabile del completamento della progettazione del sistema DNS per Windows 2000.
Se l'organizzazione migra da Windows NT, è attualmente presente una persona a supporto della risoluzione dei nomi WINS. Il
proprietario del servizio DNS supporta il sistema DNS in modo analogo a quanto accade attualmente con il supporto WINS.
Il proprietario del servizio DNS ha il compito di mantenere i contatti con chi gestisce i sistemi DHCP e DNS dell'organizzazione.
È opportuno coinvolgere tali gruppi nel processo di progettazione del sistema DNS per Active Directory, in modo che siano
consapevoli di quanto viene pianificato e possano fornire riscontri e suggerimenti già dalle prime fasi.
Progettazione ottimale del sistema DNS in assenza di un servizio DNS precedente
Il modello ottimale per la progettazione di un sistema DNS dipende dal fatto che nella rete sia già stato implementato o meno
tale sistema. Se il servizio DNS non è stato implementato, il proprietario della foresta e il proprietario del servizio DNS per
Active Directory devono pianificarne l'implementazione ottimale.
Nella guida complementare Best Practice Active Directory Deployment for Managing Windows Networks sono incluse istruzioni
dettagliate per il deployment del sistema DNS. Le informazioni qui presenti vengono fornite solo come riferimento.
Configurazione dei server
Nella figura 21 viene illustrata una possibile architettura DNS in relazione a un'organizzazione che in precedenza non aveva
implementato il sistema DNS.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 21 Nuova struttura DNS
In questa architettura, il server DNS che ha autorità per il nome del dominio radice della foresta ospita una zona radice
privata. Tutti gli altri server elencano i server radice DNS nei propri percorsi predefiniti.
Nella tabella 15 è inclusa una panoramica della configurazione DNS ottimale per una rete priva di un servizio DNS
preesistente.
Tabella 15 Progettazione ottimale del sistema DNS per un'organizzazione priva di un servizio DNS preesistente
Elemento di
progettazione
Configurazione
Posizionamento dei
server DNS
Il sistema DNS deve essere attivato in ogni domain controller.
Risoluzione ricorsiva dei
nomi
I percorsi predefiniti devono essere presenti in tutti i server tranne che
nei domain controller della radice della foresta.
Posizionamento delle
zone
La radice della foresta include zone per:
• Radice DNS
• Dominio radice della foresta
• _msdcs.<radice-foresta>
Ogni dominio figlio include una zona per:
• Il proprio dominio figlio
• _msdcs.<radice-foresta>
Nota Per consentire ai vari server l'individuazione reciproca dei partner di replica e ai client l'individuazione dei server che
ospitano il catalogo globale, Active Directory utilizza un gruppo speciale di record di individuazione. Active Directory
memorizza nella zona msdcs.<nome_foresta> tutti i record di individuazione che abbracciano l'intera foresta. Poiché le
informazioni presenti nella zona devono essere sempre disponibili, tale zona viene replicata in tutti i server DNS della foresta.
Configurazione della zona per i server DNS della radice della foresta
Progettare la configurazione della zona radice DNS come specificato nella tabella 16.
Tabella 16 Zona radice DNS
Elemento di progettazione
Progettazione
Tipo di zona
Integrata con Active Directory
Aggiornamenti dinamici
Disattivato
Scavenging (pulizia)
Disattivato
Deleghe della zona radice ad altre zone
Viene creata una delega per la zona della radice
della foresta. La delega include un record NS per
ogni domain controller della radice della foresta.
Progettare la configurazione della zona della radice della foresta come specificato nella tabella 17.
Tabella 17 Zona DNS della radice della foresta
Elemento di progettazione
Progettazione
Tipo di zona
Integrata con Active Directory.
Aggiornamenti dinamici
Solo aggiornamenti dinamici protetti.
Scavenging (pulizia)
Abilitato con le impostazioni predefinite.
Deleghe della zona della radice della foresta ad
altre zone
•Viene creata una delega per la zona
_msdcs.<radice-foresta>. La delega include un
record NS per ogni domain controller della radice
della foresta.
• Viene creata una delega per i domini regionali
appropriati. Ogni delega include nel dominio
regionale appropriato un record NS per tutti i
domain controller dei domini regionali.
Progettare la configurazione della zona _msdcs.<radice-foresta> come specificato nella tabella 18.
Tabella 18 Configurazione della zona _msdcs.<radice-foresta>
Elemento di progettazione
Progettazione
Tipo di zona
Integrata con Active Directory
Aggiornamenti dinamici
Solo aggiornamenti dinamici protetti
Scavenging (pulizia)
Attivato
Configurazione della zona dei server DNS di un dominio regionale
La zona di un dominio regionale viene configurata come specificato nelle tabelle 19 e 20.
Tabella 19 Zona del dominio figlio
Elemento di progettazione
Progettazione
Tipo di zona
Integrata con Active Directory
Aggiornamenti dinamici
Solo aggiornamenti dinamici protetti
Scavenging (pulizia)
Attivato
Tabella 20 Configurazione della copia secondaria della zona _msdcs.<radice-foresta>
Elemento di progettazione
Progettazione
Tipo di zona
Secondaria
Aggiornamenti dinamici
Non applicabile
Scavenging (pulizia)
Non applicabile
Altra configurazione
L'origine per il trasferimento della zona è un
server DNS in un domain controller vicino della
radice della foresta
Configurazione del client
Per configurare il client DNS, il proprietario del servizio DNS per Active Directory deve specificare lo schema di denominazione
dei computer e il modo in cui il client individua i server DNS. Nella tabella 21 sono riepilogate tali specifiche.
Tabella 21 Configurazione client per il sistema DNS quando manca un servizio DNS preesistente
Elemento di progettazione
Configurazione
Denominazione dei computer
Utilizzare il sistema di denominazione
predefinito. Quando un computer Windows 2000
viene unito a un dominio, assegna a se stesso un
nome DNS primario costituito dal nome host del
computer e dal nome del dominio.
Configurazione del resolver per i client
Configurare i client con gli indirizzi di almeno due
server DNS attivi nei domain controller Active
Directory.
Nella figura 22 viene illustrato un modello di configurazione dei client, nel quale è prevista la presenza di un server DHCP ma
non quella di un server DNS o di una soluzione integrata DNS/DHCP.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 22 Denominazione dei computer senza il sistema DNS ma con un servizio DHCP esistente
In questo esempio, un server DHCP assegna un indirizzo IP al computer Server.noam.corp.contoso.com. Il computer registra il
proprio nome DNS nella nuova infrastruttura DNS. Quando un client chiede al sistema DNS il nome del computer, il server
DNS lo trova e risolve la query.
Grazie a questo modello non è necessario apportare modifiche al servizio DHCP già presente.
Progettazione ottimale del sistema DNS in presenza di un servizio DNS preesistente
Il modello ottimale per la progettazione di un sistema DNS dipende dal fatto che nella rete sia già stato implementato o meno
un tale sistema. Se è già stato implementato un servizio DNS, il proprietario della foresta e il proprietario del servizio DNS per
Active Directory collaborano con il proprietario del servizio DNS attuale per delegare il nome DNS del dominio radice della
foresta ad Active Directory e configurare un servizio DNS integrato con Active Directory.
Nella guida complementare Best Practice Active Directory Deployment for Managing Windows Networks sono incluse istruzioni
dettagliate per l'esecuzione del deployment del sistema DNS. Le informazioni qui presenti vengono fornite solo come
riferimento.
Configurazione dei server
Nella tabella 22 è fornita una panoramica della configurazione DNS ottimale per una rete già dotata di un servizio DNS.
Tabella 22 Progettazione ottimale del sistema DNS per un'organizzazione già dotata di un servizio DNS
Elemento di progettazione
Configurazione
Posizionamento dei server DNS
Il sistema DNS deve essere attivo in ogni domain
controller.
Risoluzione ricorsiva dei nomi
Stabilire se il servizio DNS esistente utilizza il
sistema di inoltro o i percorsi predefiniti.
Configurare il sistema DNS in esecuzione nei
domain controller in modo che sia impostato in
modo uniforme.
Posizionamento delle zone
La radice della foresta include zone per:
• Dominio radice della foresta
• _msdcs.<radice-foresta>
Ogni dominio regionale include una zona per:
• Il proprio dominio figlio
• _msdcs.<radice-foresta>
Nota Per consentire ai vari server l'individuazione reciproca dei partner di replica e ai client l'individuazione dei server che
ospitano il catalogo globale, Active Directory utilizza un gruppo speciale di record di individuazione. Active Directory
memorizza nella zona msdcs.<nome_foresta> tutti i record di individuazione che abbracciano l'intera foresta. Poiché le
informazioni presenti nella zona devono essere sempre disponibili, tale zona viene replicata in tutti i server DNS della foresta.
Quest'architettura ha il vantaggio di lasciare intatta la struttura DNS esistente. Non è necessario eseguire la migrazione di
server o zone. Vengono semplicemente aggiunti domini alla gerarchia DNS esistente nello stesso modo previsto dagli ideatori
del sistema DNS al momento della stesura dei documenti RFC.
Nota Sebbene esistano altre implementazioni di server DNS in grado di supportare Active Directory, l'utilizzo di un sistema
DNS integrato con Windows 2000 Active Directory rappresenta la soluzione migliore, in quanto qui è supportato
l'aggiornamento dinamico protetto.
La configurazione dei server varia a seconda che per la risoluzione ricorsiva dei nomi il servizio DNS vengano utilizzati i
percorsi predefiniti o l'inoltro.
Percorsi predefiniti
Nella figura 23 viene illustrato il modello di configurazione dei server di una rete che utilizza i percorsi predefiniti. Un server
DNS ospita una zona radice. Essa può essere una zona Internet o una zona privata. Ai fini della configurazione questa
distinzione è irrilevante.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 23 Integrazione con il servizio esistente mediante i percorsi predefiniti
In questo esempio, i server DNS includono i percorsi predefiniti, che indicano gli indirizzi dei server DNS della radice. Quando
un server DNS deve risolvere una query ma non è in grado di farlo ricorrendo alla propria cache o ai file della zona, interroga il
server DNS della radice.
Inoltro
Nella figura 24 viene illustrato il modello di configurazione dei server di una rete che utilizza l'inoltro.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 24 Integrazione con il servizio esistente mediante l'inoltro
In questa configurazione, i server DNS figlio inoltrano le query al server DNS della radice della foresta più vicino, il quale a sua
volta le inoltra allo stesso server d'inoltro utilizzato attualmente dai server DNS esistenti.
Configurazione della zona per i server DNS della radice della foresta
Progettare la configurazione della zona DNS della radice della foresta come specificato nella tabella 23.
Tabella 23 Zona DNS della radice della foresta
Elemento di progettazione
Progettazione
Tipo di zona
Integrata con Active Directory.
Aggiornamenti dinamici
Solo aggiornamenti dinamici protetti.
Scavenging (pulizia)
Attivato.
Deleghe della zona radice ad altre zone
• Viene creata una delega per la zona
_msdcs.<radice-foresta>. La delega include i
record NS relativi a tutti i domain controller della
radice della foresta.
• Le deleghe vengono create per i domini
regionali appropriati. Ogni delega include nel
dominio regionale appropriato un record NS per
tutti i domain controller dei domini regionali.
Altra configurazione
La zona padre viene aggiornata al fine di
includere una delega per tale zona.
Progettare la configurazione della zona DNS _msdcs.<radice-foresta> come specificato nella tabella 24.
Tabella 24 Zona DNS _msdcs.<radice-foresta>
Elemento di progettazione
Progettazione
Tipo di zona
Integrata con Active Directory
Aggiornamenti dinamici
Solo aggiornamenti dinamici protetti
Scavenging (pulizia)
Attivato
Configurazione della zona per i server DNS del dominio regionale
La zona di ogni dominio regionale viene configurata come specificato nelle tabelle 25 e 26.
Tabella 25 Zona del dominio regionale
Elemento di progettazione
Progettazione
Tipo di zona
Integrata con Active Directory
Aggiornamenti dinamici
Solo aggiornamenti dinamici protetti
Scavenging (pulizia)
Attivato
Tabella 26 Configurazione della copia secondaria della zona _msdcs.<radice-foresta>
Elemento di progettazione
Progettazione
Tipo di zona
Secondaria
Aggiornamenti dinamici
Non applicabile
Scavenging (pulizia)
Non applicabile
Altra configurazione
L'origine per il trasferimento della zona è un
server DNS attivo in un domain controller vicino
della radice della foresta
Configurazione del client
Per configurare il client DNS, il proprietario DNS per Active Directory deve specificare lo schema di denominazione dei
computer e il modo in cui il client individua i server DNS. Nella tabella 27 sono riepilogate tali specifiche.
Tabella 27 Configurazione client per il sistema DNS quando è presente un servizio DNS preesistente
Elemento di progettazione
Configurazione
Denominazione dei computer
Utilizzare il sistema di denominazione
predefinito. Quando un computer Windows 2000
viene unito a un dominio, assegna a se stesso un
nome DNS primario costituito dal nome host del
computer e dal nome del dominio.
Configurazione del resolver per i client
Per i client esistenti, non modificare la
configurazione del resolver. Non è necessario
che i client Windows 2000 facciano riferimento
diretto a un server DNS Windows 2000. Può
essere utilizzato qualsiasi server DNS della rete.
Se il nome dei client è già registrato nel sistema DNS, tali client hanno a questo punto due nomi: quello precedente e quello
nuovo primario. I client possono essere individuati con entrambi i nomi. I nomi primari vengono automaticamente creati e
aggiornati mediante l'aggiornamento dinamico e automaticamente ripuliti tramite la funzionalità di scavenging (pulizia).
Un computer può disporre di un nome DNS già esistente se in precedenza l'organizzazione ha implementato:
•
•
Un servizio DNS.
Una soluzione integrata DHCP/DNS.
Nota L'utilizzo di un sistema di denominazione predefinito per i client Windows 2000 non incide sui meccanismi di
autenticazione presenti nella rete esistente.
Se si desidera trarre vantaggio dall'autenticazione Kerberos quando ci si connette a un server che esegue Windows 2000, è
necessario accertarsi che il client si connetta al server utilizzando il nome primario.
Ognuna di tali architetture lascia intatta qualsiasi soluzione DNS, DHCP o DNS/DHCP integrata. È possibile utilizzare un suffisso
DNS al posto del nome del dominio Active Directory se i nomi DNS e Active Directory differiscono. Tuttavia, a motivo dell
ulteriore carico gestionale di tale configurazione, non è consigliabile.
Nota Se sono già state configurate zone di ricerca inversa, lasciarle come sono, come pure tutti i record PTR. Tutti i client
esistenti possono continuare a essere registrati utilizzando i nomi esistenti.
Client con nomi registrati staticamente in un server DNS esistente
Nel modello esaminato, sulla rete è già presente un server DNS, nel quale l'amministratore immette manualmente i nomi.
Nella figura 25 viene illustrato un esempio di tale configurazione.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 25 Denominazione dei computer con un servizio DNS già esistente
In questo esempio, il server DNS esistente ospita una zona contenente il nome Server.seattle.contoso.com. Dopo essere
entrato a far parte del dominio, il server registra anche un nuovo nome (Server.noam.concorp.contoso.com) in un server DNS
che viene attivato in un domain controller.
Mediante uno dei due nomi DNS qualsiasi client è in grado di individuare il server. Quando un client interroga un server DNS,
quest'ultimo esegue la risoluzione del nome al fine di individuarne il corrispondente indirizzo IP. A seconda del modo in cui è
configurato il sistema DNS, il server DNS può inoltrare la query o utilizzare la risoluzione ricorsiva dei nomi. In entrambi i casi,
il server DNS chiede al server appropriato il giusto nome e quindi risponde al client nel modo più opportuno.
Questo modello non incide su alcun sistema di denominazione DNS eventualmente presente. Se, prima di eseguire il
deployment, il server DNS ospita una zona contenente nomi di computer, questa situazione può perdurare anche dopo il
deployment.
Client con nomi registrati mediante una soluzione DHCP/DNS integrata
In questo modello, la rete esistente utilizza una soluzione DHCP/DNS integrata, ad esempio Lucent QIP. Nella figura 26 viene
illustrato un esempio di tale configurazione.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 26 Denominazione dei computer con una soluzione DHCP/DNS integrata
In questo esempio, il server Server.seattle.contoso.com si avvale del server DHCP per registrare il proprio nome nel server
DNS e per fornire un indirizzo IP. Dopo essere entrato a far parte di un dominio, il server registra anche un nuovo nome
(Server.noam.corp.contoso.com) in un server DNS attivo in un domain controller.
Mediante uno dei due nomi DNS qualsiasi client è in grado di individuare il server. Quando un client interroga un server DNS,
quest'ultimo esegue la risoluzione del nome al fine di individuarne il corrispondente indirizzo IP. A seconda del modo in cui è
configurato il sistema DNS, il server DNS può inoltrare la query o utilizzare la risoluzione ricorsiva dei nomi. In entrambi i casi,
il server DNS chiede al server appropriato il giusto nome e quindi risponde al client nel modo più opportuno.
Questo modello non incide su alcuna soluzione DHCP/DNS integrata eventualmente presente. Se, prima di eseguire il
deployment, il server DHCP registra i nomi DNS dei computer, questa situazione può perdurare anche dopo il deployment.
Processo di progettazione del sistema DNS
Il processo di pianificazione del sistema DNS consente di realizzare un'architettura DNS ottimale. I passaggi implicati in tale
processo sono:
1.
2.
3.
4.
5.
Pianificazione del posizionamento dei server DNS.
Pianificazione della risoluzione ricorsiva dei nomi.
Configurazione delle zone DNS.
Pianificazione della denominazione dei computer.
Pianificazione della configurazione del resolver per i client.
La figura 27 descrive il processo di progettazione del sistema DNS.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 27 Flusso delle attività di progettazione del sistema DNS per Active Directory
Le decisioni da prendere nella pianificazione del sistema DNS sono semplici e automatiche. Se esiste già una struttura DNS,
essa impone molte di tali scelte. Nel corso della progettazione di ogni componente, riempire le parti pertinenti del foglio di
lavoro DNS corrispondente. Al termine, esaminare il progetto insieme ai gruppi DNS e DHCP esterni.
Il passaggio successivo
Nell'ambito della progettazione dei domini, il proprietario della foresta ha assegnato la proprietà dei domini. Ogni dominio
previsto durante il processo di progettazione ha un proprietario. Ogni proprietario di dominio può a questo punto procedere in
modo indipendente al passaggio successivo del processo di progettazione, descritto nella sezione che segue.
Creazione dell'architettura delle unità organizzative
Dopo aver completato la pianificazione dei domini, è possibile progettare la struttura delle unità organizzative. In un modello
ottimale di progettazione delle unità organizzative, i reparti che fanno parte del dominio gestiscono le proprie operazioni
interne, mentre il personale IT del dominio gestisce l'infrastruttura complessiva. In altri termini, ogni reparto gestisce i propri
oggetti nella directory, mentre il personale IT del dominio si occupa della configurazione del servizio di directory.
Le metodologie ottimali per la creazione di un'architettura di unità organizzative prevedono un nuovo ruolo, ovvero quello del
proprietario di unità organizzativa. Il proprietario di un'unità organizzativa Active Directory è simile alla maggior parte degli
amministratori di dominio Windows NT. Pertanto, gli amministratori che gestiscono utenti e risorse di un dominio Windows NT
gestiranno le stesse risorse in un dominio Active Directory, ma saranno detti proprietari di unità organizzative.
È prevedibile che periodicamente sia necessario apportare modifiche alla struttura delle unità organizzative per riflettere i
cambiamenti della struttura amministrativa e per supportare l'amministrazione basata sui criteri. Le unità organizzative
devono essere progettate per poter essere modificate con facilità.
Ruolo delle unità organizzative nell’architettura delle reti Windows
Le unità organizzative sono contenitori inclusi nei domini in grado di contenere altre unità organizzative, utenti, gruppi,
computer e altri oggetti. Tali unità organizzative e sotto-unità organizzative formano una struttura gerarchica all'interno del
dominio e vengono utilizzate prevalentemente per raggruppare gli oggetti per scopi gestionali.
Nota Non esistono limiti pratici al numero di livelli di nidificazione delle unità organizzative. Quando si progettano i sottolivelli
delle unità organizzative, è necessario considerare che al vantaggio derivante dal maggiore livello di dettaglio corrisponde
un'accresciuta complessità della gestione della struttura. Pertanto è consigliabile creare strutture di unità organizzative con un
massimo di dieci livelli.
Quando si progetta una struttura di unità organizzative, è opportuno rammentare che la gerarchia di unità organizzative non
deve necessariamente rispecchiare la gerarchia dei reparti dell'organizzazione. Ogni unità organizzativa creata deve avere uno
scopo definito (ad esempio delega o criterio di protezione) e incrementare il valore del sistema. In caso contrario, si
trascorrerebbe più tempo a gestire la struttura senza beneficiare di un corrispondente vantaggio.
Lo scopo iniziale della progettazione di una struttura di unità organizzative è rappresentato dalla delega dell'amministrazione.
Dopo avere posto in esercizio questa struttura, è possibile migliorarla creando altri sottolivelli di unità organizzative necessari
per altri scopi, ad esempio l'applicazione di criteri di gruppo o la collocazione di oggetti in unità organizzative distinte per
limitarne la visibilità.
Delega dell'amministrazione
La delega dell'amministrazione consente di designare gruppi di utenti che controllino utenti, computer o altri oggetti inclusi in
un'unità organizzativa. A tale scopo, inserire in un gruppo l'utente che deve esercitare il controllo, includere in un'unità
organizzativa una serie di oggetti da controllare e quindi delegare l'amministrazione dell'unità organizzativa a tale gruppo. In
Windows 2000 è possibile controllare in modo molto dettagliato le attività amministrative delegabili. Ad esempio, è possibile
creare un gruppo che controlli totalmente tutti gli oggetti di un'unità organizzativa, un altro gruppo che possa solo creare,
delegare e gestire gli account utente dell'unità organizzativa e infine un altro gruppo in grado solo di reimpostare le password
degli account utente. Queste autorizzazioni possono essere rese ereditabili, in modo che riguardino non un solo contenitore,
ma anche i suoi sotto-contenitori.
Nell'ambito della delega dell'amministrazione, le unità organizzative prendono il posto dei domini Windows NT, al fine di:
•
•
Ridurre al minimo il numero di amministratori che devono disporre di livelli di accesso elevati.
Rendere i singoli gruppi dell'organizzazione responsabili dell'amministrazione locale.
Criteri di gruppo (Group Policy)
Sebbene la struttura delle unità organizzative venga creata innanzitutto per la delega dell'amministrazione, alcune
organizzazioni creano ulteriori livelli di unità organizzative per l'implementazione dei criteri di gruppo.
I criteri di gruppo possono utilizzare i gruppi di protezione per delimitare il proprio ambito, ovvero per applicare
un'impostazione a un sottoinsieme di oggetti di un'unità organizzativa senza dover creare una sotto-unità organizzativa. Ad
esempio, è possibile creare un'impostazione di criterio di gruppo da applicare solo ai responsabili, anche se le unità
organizzative contengono tutti gli utenti. A tale scopo, l'impostazione va applicata all'unità organizzativa, quindi è necessario
creare un gruppo di responsabili e modificare le autorizzazioni previste dal criterio in modo da applicarle solo a quel gruppo. Al
contrario, per delegare l'amministrazione di un sottoinsieme di un'unità organizzativa è necessario creare una sotto-unità
organizzativa. Poiché grazie ai gruppi di protezione è possibile ottenere un controllo preciso dell'ambito dei criteri di gruppo, la
delega dell'amministrazione ha la priorità nel processo di progettazione delle unità organizzative.
Nota Non è possibile applicare le impostazioni dei criteri di gruppo ai contenitori predefiniti Users e Computers. Essi non sono
unità organizzative, pertanto non è possibile includervi unità organizzative né utilizzarli per i criteri di gruppo.
È consigliabile accettare i valori predefiniti impostati nei contenitori Default Domain Policy e Default Domain Controllers Policy,
ad eccezione dei nodi indicati di seguito, i quali includono impostazioni da personalizzare per rispondere alle proprie esigenze
di sicurezza.
•
•
Default Domain Policy
o Criterio relativo alle password
o Criterio di blocco degli account
o Criterio relativo a Kerberos
Default Domain Controllers Policy
o Assegnazione diritti utente
Le altre impostazioni dei criteri di gruppo (quelle non correlate alla sicurezza) non dovrebbero essere specificate all'interno di
tali impostazioni predefinite. È invece necessario creare nuovi oggetti per i criteri di gruppo (Group Policy Object, GPO). Per
ulteriori informazioni sulla pianificazione e l'implementazione dei criteri di gruppo, vedere gli argomenti seguenti:
•
Per la pianificazione dei criteri di gruppo, vedere Windows 2000 Change and Configuration Management Deployment
Guide, disponibile all'indirizzo:
http://www.microsoft.com/windows2000/techinfo/reskit/deploy/CCM/default.asp
•
Per i modelli relativi agli oggetti per i criteri di gruppo in sei diversi scenari di gestione, vedere Implementing
Common Desktop Management Scenarios, disponibile all'indirizzo:
http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolicy.asp
•
Criteri di gruppo:
http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp
•
Gestione degli utenti:
http://www.microsoft.com/windows2000/techinfo/administration/management/settings.asp
Elementi di un piano per la progettazione di unità organizzative
Il proprietario del dominio è responsabile del completamento della progettazione delle unità organizzative del proprio dominio.
Nella progettazione è necessario includere:
•
•
Un diagramma della gerarchia delle unità organizzative.
L'elenco delle unità organizzative. Per ogni unità organizzativa:
o Lo scopo.
o L'elenco degli utenti e dei gruppi che controllano l'unità organizzativa o degli oggetti in essa inclusi.
o Il tipo di controllo esercitato sulla classe degli oggetti contenuti nell'unità organizzativa.
Annotare le risposte nei fogli di lavoro della progettazione delle unità organizzative inclusi più avanti in questa guida.
Ruolo dei proprietari delle unità organizzative
Il proprietario del dominio designa un proprietario per ogni unità organizzativa. Il proprietario di un'unità organizzativa è un
amministratore di dati che detiene il controllo di una sottostruttura di oggetti di Active Directory. I proprietari di unità
organizzative non possiedono, e tanto meno controllano, il funzionamento del servizio, che rimane sotto il controllo del
proprietario del dominio. In questo modo è possibile separare la proprietà e l'amministrazione del servizio da quella degli
oggetti del servizio stesso, nonché ridurre il numero di amministratori del servizio con livelli di accesso elevati.
Nota Sebbene al proprietario dell'unità organizzativa venga delegato il controllo di una sottostruttura di oggetti, il proprietario
del dominio conserva il controllo totale di tutte le sottostrutture. È consigliabile non modificare questa impostazione affinché il
proprietario del dominio possa correggere eventuali errori, ad esempio un elenco di controllo di accesso (ACL, Access Control
List) inadeguato oppure il ripristino di sottostrutture andate perse a motivo della cancellazione dei rispettivi amministratori.
I compiti di gestione dei proprietari di unità organizzative includono la possibilità di controllare la delega delle funzioni
amministrative e di verificare l'applicazione dei criteri agli oggetti. Essi possono inoltre creare nuove sottostrutture e delegare
l'amministrazione delle unità organizzative.
Modello ottimale per la progettazione di unità organizzative
Nel modello ottimale per la progettazione di unità organizzative ogni dominio include un insieme standard di unità
organizzative, indipendentemente dal fatto che il dominio sia stato aggiornato o creato. In entrambi i casi, il controllo
amministrativo viene delegato a un proprietario di dati.
Nella figura 28 vengono illustrati gli elementi del modello, il quale potrebbe essere diverso dalla gerarchia delle unità
organizzative di un progetto reale, in esso, infatti, sono indicate le due possibili posizioni delle unità organizzative che
contengono solo risorse: esse possono essere poste sotto la radice del dominio e sotto un'unità organizzativa che contiene gli
account utente. La struttura progettata può includere entrambi i tipi di unità oppure uno solo dei due. Per ulteriori
informazioni, vedere "Unità organizzative per le risorse" di seguito in questa sezione.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 28 Panoramica del modello ottimale di unità organizzative
Unità organizzative e contenitori predefiniti
Esistono diversi contenitori predefiniti Active Directory, tra cui:
•
•
Contenitori Users e Computers
Unità organizzativa Domain Controllers
Questi contenitori devono rimanere sotto il controllo del proprietario del dominio.
Contenitori Users e Computers
A seguito dell’aggiornamento di un dominio Windows NT alla modalità nativa di Windows 2000, gli utenti e i computer esistenti
vengono automaticamente inseriti nei contenitori Users e Computers. Tuttavia, questi contenitori non vengono utilizzati.
Infatti, gli utenti e i computer vengono poi spostati nelle unità organizzative sotto il controllo dei singoli proprietari di dati.
Nota Se il dominio Windows NT viene gestito con strumenti di versioni precedenti, ad esempio User Manager, o con strumenti
di terze parti, gli utenti e i gruppi nuovi vengono inseriti nel contenitore Users del dominio Active Directory. Fino a quando non
viene completato l'aggiornamento degli strumenti, gli utenti devono essere spostati manualmente nelle unità organizzative
appropriate.
Quando un computer entra a far parte di un dominio Active Directory ed è privo di un account, ne viene creato uno
automaticamente nel contenitore Computers. Se si desidera evitare questa operazione, creare in anticipo l'account del
computer nell'unità organizzativa appropriata.
Account già noti e predefiniti
Per impostazione predefinita, in un nuovo dominio vengono creati automaticamente numerosi utenti e gruppi. Questi oggetti
devono rimanere nei contenitori predefiniti e sotto il controllo del proprietario del dominio. Nella tabella 28 vengono elencati gli
utenti e i gruppi appena descritti.
Tabella 28 Elenco degli utenti e dei gruppi noti e degli account incorporati
Utenti/gruppi noti
Account predefiniti
Administrator
Guest
KRBTGT
Domain Admins
Domain Users
Domain Guests
Domain Computers
Cert Publishers
Schema Admins (solo dominio radice)
Enterprise Admins (solo dominio radice).
Administrator
Guest
Internet Guest Account
Launch IIS Process Account
Unità organizzativa Domain Controllers
Agli oggetti creati nel dominio e nelle unità organizzative Domain Controllers vengono applicate le impostazioni predefinite dei
criteri di gruppo. È consigliabile non modificare il contenuto di questi contenitori e le rispettive impostazioni dei criteri di
gruppo. Solo in caso di necessità il proprietario del dominio può creare nuove impostazioni dei criteri di gruppo.
Unità organizzative dedicate agli account
Le unità organizzative dedicate agli account consentono di gestire le identità, ovvero consentono di definire l'insieme di utenti
e di gruppi a cui può essere accordato l'accesso alle risorse. Esse corrispondono ai domini MUD di Windows NT. Nella figura 29
viene illustrato un modello di unità organizzativa dedicata agli account.
Figura 29 Modello di unità organizzativa dedicata agli account
Nella tabella 29 vengono elencate e descritte le unità organizzative create nella struttura di un'unità organizzativa dedicata agli
account.
Tabella 29 Unità organizzative create mediante gli utenti e i computer migrati dai domini MUD di Windows NT
Unità
organizzativa
Scopo
Users
Account utente per il personale senza compiti amministrativi.
Service Accounts
Alcuni servizi che necessitano dell'accesso a risorse di rete necessitano di un
contesto di esecuzione assegnato ad un account utente. Questa unità
organizzativa viene creata per separare e distinguere gli account utente dei
servizi dagli account utente delle persone, che sono inclusi nell'unità
organizzativa Users. Inoltre, inserendo i diversi tipi di account utente in unità
organizzative distinte, è possibile gestirli in base ai differenti requisiti
amministrativi.
Computers
Account di computer che non siano domain controller.
Groups
Tutti i tipi di gruppi, ad eccezione dei gruppi amministrativi, che vengono gestiti
separatamente.
Admins
Account utente e di gruppo per personale con compiti amministrativi, per
consentire una gestione separata dagli utenti normali. Il controllo di questa unità
organizzativa consente di tenere traccia delle modifiche degli utenti e dei gruppi
con compiti amministrativi.
Amministrazione delle unità organizzative dedicate agli account
Nella figura 30 vengono delineati i gruppi amministrativi progettati per un'unità organizzativa dedicata agli account. Si tratta di
gruppi locali. Creare il proprietario dell'unità organizzativa dedicata agli account. In questo esempio, il gruppo chiamato
<acct_ou>_OU_admins ha un controllo totale dell'unità organizzativa e consente di creare le sottounità organizzative standard
nonché i gruppi per gestirle.
Ai gruppi che gestiscono le sottounità organizzative viene accordato il controllo completo della sola classe di oggetti che
dovranno gestire. Ad esempio, <acct_ou>_group_admins controlla unicamente i gruppi.
Non esiste un gruppo amministrativo distinto per gestire l'unità organizzativa Admins. La sua proprietà appartiene all'unità
organizzativa padre, pertanto viene gestita da <acct_ou>_OU_admins.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 30 Gruppi amministrativi di un'unità organizzativa dedicata agli account
Il proprietario dell'unità organizzativa può decidere di creare ulteriori gruppi amministrativi. Ad esempio, può creare nell'unità
organizzativa Admins il gruppo facoltativo <acct_ou>_helpdesk_admins, con potere di controllo sulla reimpostazione delle
password.
Unità organizzative per le risorse
Le unità organizzative per le risorse sono utilizzate per gestire l'accesso alle risorse. Esse sono analoghe ai domini di risorse
Windows NT. Il proprietario dell'unità organizzativa crea gli account di computer mediante i quali includere nel dominio i server
di risorse quali condivisioni di file, database e stampanti. Il proprietario crea inoltre i gruppi che consentono di controllare
l'accesso alle risorse. Nella figura 31 sono illustrate le due posizioni possibili delle unità organizzativa per le risorse.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 31 Modello di unità organizzativa per le risorse
Il modello di progettazione delle unità organizzativa per le risorse differisce da quello delle unità organizzativa dedicata agli
account per tre motivi:
•
La posizione all'interno della gerarchia amministrativa delle unità organizzative.
Se sono presenti domini di risorse Windows NT gestiti in modo indipendente da gruppi IT distinti, è possibile inserire
le nuove unità organizzative nel livello superiore, appena al di sotto della radice del dominio. Se il proprietario di un
dominio MUD di Windows NT detiene e gestisce il contenuto del dominio di risorse precedente, l'unità organizzativa
per le risorse può essere creata come sottounità della corrispondente unità organizzativa dedicata agli account.
Nota I proprietari di un dominio di risorse possono scegliere di essere subordinati al proprietario di un dominio MUD
di Windows NT piuttosto che al proprietario del dominio, al fine di ottenere una migliore assistenza. Ad esempio, se in
seguito a un errore amministrativo gli oggetti dell'unità organizzativa di risorse non sono più accessibili,
l'amministratore della risorsa necessiterà dell'assistenza di un amministratore di livello superiore. Nelle organizzazioni
di grandi dimensioni il proprietario di un dominio MUD di Windows NT di solito è più vicino e gestisce un ambito
piuttosto ristretto.Al contrario, il proprietario del dominio in genere si trova in una regione o in una nazione diversa
ed è responsabile di un gran numero di unità organizzative.
•
Struttura a unità organizzativa singola.
Le unità organizzative per le risorse non includono sottounità organizzative standard. I computer e i gruppi vengono
inseriti direttamente nell'unità organizzativa.
•
Il proprietario dell'unità organizzativa per le risorse è proprietario dei soli oggetti inclusi nell'unità stessa.
Il proprietario dell'unità organizzativa di risorse non possiede il contenitore dell'unità stessa. Egli si limita a gestire gli
oggetti computer e gruppo e non può creare altre classi di oggetti all'interno dell'unità organizzativa. Questa
impostazione consente di limitare le capacità gestionali dei proprietari di unità organizzative per le risorse
unicamente agli oggetti computer e gruppo nonché di impedire loro la creazione di sottounità organizzative.
Nota Il creatore o il proprietario di un oggetto può normalmente impostare l'ACL per i propri oggetti, indipendentemente dalle
autorizzazioni ereditate dal contenitore padre. Se il proprietario di un'unità organizzativa per le risorse potesse reimpostare
l'ACL per un'unità organizzativa, egli sarebbe in grado di creare qualsiasi classe di oggetti nell'unità organizzativa, ad esempio
gli utenti. Per questo motivo, ai proprietari delle unità organizzative delle risorse non è consentito creare nuove unità
organizzative.
Nella figura 32 viene delineato il gruppo amministrativo progettato per un'unità organizzativa di risorse. Per ogni unità
organizzativa destinata alla gestione delle risorse, creare un gruppo che sia il proprietario delle risorse. Questo gruppo
controlla gli oggetti gruppo e computer dell'unità organizzativa, ma non il contenitore dell'unità stessa. Il gruppo
<res_ou>_OU_admin gestisce in proprio l'appartenenza al gruppo e si trova nell'unità organizzativa per le risorse.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 32 Struttura di un gruppo amministrativo per un'unità organizzativa destinata alla gestione delle risorse
Nota In Windows NT i proprietari di domini di risorse controllano in genere in modo completo i computer entrati a far parte dei
rispettivi domini in quanto sono diventati automaticamente membri del gruppo locale Admins in tutti i computer dei
corrispondenti domini. In un'unità organizzativa di risorse, l'amministratore locale di tutti computer è l'amministratore del
dominio. Per accordare agli amministratori delle unità organizzative per le risorse il controllo totale dei computer di un'unità
organizzativa, utilizzare i criteri di gruppo specificando le apposite restrizioni. Per ulteriori informazioni, consultare la
documentazione relativa ai criteri di gruppo.
Processo di progettazione delle unità organizzative
Il proprietario del dominio progetta la struttura delle unità organizzative del dominio mediante la creazione di unità
organizzative dedicate agli account e alle risorse, come illustrato nella figura 33.
Figura 33 Flusso delle attività di progettazione delle unità organizzative
Creazione delle unità organizzative dedicate agli account
Verificare nel progetto se un determinato dominio è il risultato di un aggiornamento da Windows NT o è stato creato ex novo e
se è destinato al consolidamento dei domini MUD. Attenersi alla procedura seguente per creare le unità organizzative di
account:
1.
Se il dominio proviene da un’aggiornamento, occorre creare un'unità organizzativa per gli account aggiornati.
Durante il deployment, gli utenti e i gruppi che appartengono al proprietario del dominio vengono distinti da quelli
normali. Gli utenti e i gruppi del proprietario del dominio restano nel contenitore Users predefinito, mentre gli utenti
e i gruppi normali vengono spostati nell'unità organizzativa dedicata agli account appropriata.
2.
Se il dominio è destinato a consolidare dei domini MUD di Windows NT, occorre creare un'unità organizzativa per ogni
dominio MUD di origine gestito in modo indipendente.
Se nel dominio vengono consolidati più domini MUD gestiti dallo stesso gruppo IT, è possibile eseguire la migrazione
degli account da tali domini in un'unica unità organizzativa dedicata agli account invece di utilizzare più unità
organizzative distinte.
3.
Se il dominio è di nuova costituzione, creare un'unità organizzativa dedicata agli account per il dominio stesso.
Questa unità organizzativa è necessaria per separare il proprietario dei dati dell'unità stessa dal proprietario dei
servizi del dominio.
Creazione delle unità organizzative per le risorse
Verificare nel progetto se un determinato dominio è destinato al consolidamento di domini di risorse nell'architettura Windows
NT corrispondente.
In caso affermativo:
1.
Creare un'unità organizzativa per ogni dominio di risorse di origine gestito in modo indipendente.
Se nel dominio vengono consolidati più domini di risorse gestiti dallo stesso gruppo IT, è possibile eseguire la
migrazione degli oggetti da tali domini in un'unica unità organizzativa per le risorse invece di utilizzare più unità
organizzative distinte.
Per i domini di risorse gestiti dai proprietari dei domini MUD di Windows NT, è possibile eseguire la migrazione degli
oggetti nella corrispondente sottostruttura dell'unità organizzativa dedicata agli account (sottounità Computers e
Groups) invece di utilizzare un'unità organizzativa specifica per le risorse inclusa nell'unità organizzativa dedicata agli
account.
2.
Posizionare l'unità organizzativa al di sotto della radice del dominio oppure all'interno di un'unità organizzativa
dedicata agli account. Il proprietario del dominio di risorse diventa il proprietario dell'unità organizzativa.
Se il dominio è di nuova costituzione, creare le necessarie unità organizzative per le risorse in base ai requisiti amministrativi.
Creazione della topologia dei siti
Per sito si intende un insieme di subnet IP connesse tra di loro con velocità analoga o superiore a quella di una rete LAN. Per
definire correttamente la topologia dei siti, occorre specificare come “siti” le aree con connettività ad alta velocità e come
“collegamenti di sito” le connessioni WAN disponibili tra di esse. Dopo aver creato i siti e i collegamenti di sito, in Active
Directory viene generata automaticamente la topologia di replica tra i domain controller. Definendo i siti in base alla topologia
LAN/WAN, è possibile evitare connessioni WAN inutili e costose, a meno che non sia proprio necessaria la comunicazione tra
siti.
Ruolo della topologia dei siti nell’architettura delle reti Windows
I siti Active Directory sono un insieme di subnet IP che formano una rete veloce e sono connessi tra loro mediante i
collegamenti di sito. In Active Directory i siti vengono utilizzati per:
•
•
Ottimizzare la replica tra i domain controller.
Individuare il domain controller più vicino per l'accesso da parte dei client e per le ricerche nella directory.
Controllo della replica
La topologia dei siti controlla la replica di Active Directory in modo da ottenere l'equilibrio ottimale tra velocità e costo, grazie
alla distinzione tra la replica all'interno di un sito e la replica che deve abbracciare più siti.
All'interno dei siti, la replica viene ottimizzata in modo da garantire una velocità ottimale: gli aggiornamenti dei dati attivano la
replica, e i dati vengono inviati senza compressione. La replica tra i siti, invece, viene compressa per minimizzare il costo di
trasmissione attraverso i collegamenti WAN.
Indirizzamento della replica
Per la replica in Active Directory viene utilizzato un metodo multimaster di archiviazione e inoltro. Un domain controller
comunica le modifiche di directory a un altro domain controller, il quale a sua volta le comunica a un terzo domain controller e
così via, fino a quando tutti i domain controller le hanno ricevute. Quando si verifica la replica tra siti, un domain controller di
ogni dominio di ciascun sito (bridgehead server) raccoglie le modifiche di directory, le archivia e le comunica all'ora pianificata
a un domain controller di un altro sito.
Affinità client
I client Active Directory individuano i domain controller in base al sito in cui sono inclusi. Un client individua un domain
controller all'interno dello stesso sito ogniqualvolta sia possibile. In questo modo si evita che le comunicazioni passino anche
attraverso i collegamenti WAN.
Topologie di rete
La topologia di rete di un'organizzazione deve rifletterne le esigenze. In alcune organizzazioni, per soddisfare tali esigenze è
necessario posizionare gli utenti in poche località di grandi dimensioni adeguatamente connesse tra di loro. In altre
organizzazioni gli utenti vengono invece suddivisi in tante piccole località collegate a pochi siti hub. Tali topologie di rete
rientrano in una delle tre categorie generali seguenti: ad anello, hub e spoke e topologia complessa, come illustrato nella
figura 34.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 34 Topologie di rete
Elementi della topologia dei siti
Il proprietario della foresta e il proprietario della topologia dei siti sono responsabili dell'elaborazione dell'architettura dei siti
per la foresta. Nel loro piano è necessario includere:
•
•
•
•
La mappa delle località, in cui vanno indicati:
o Il numero di utenti e di computer di ogni località.
o La velocità e l'utilizzo dei collegamenti WAN.
o Gli indirizzi IP utilizzati in ogni sito.
L'elenco di siti, in cui deve essere indicato per ognuno:
o Il nome del sito.
o Il numero di utenti e di computer.
o I domini significativi per tale sito.
o Per ogni dominio, il numero di domain controller e l'hardware specifico.
o I domain controller che sono anche server per la gestione del catalogo globale.
L'elenco dei collegamenti di sito, in cui deve essere indicato per ognuno:
o I siti connessi mediante il collegamento.
o Il costo associato a ognuno.
o Il tempo di replica previsto per ogni collegamento.
o L'intervallo di replica per ogni collegamento.
I dati relativi alla latenza della replica.
Ruolo del proprietario della topologia dei siti
Il proprietario della topologia dei siti conosce le condizioni della rete che collega i siti e ha l'autorità di modificare le
impostazioni in Active Directory per implementare i cambiamenti necessari della topologia dei siti. Tali cambiamenti incidono
anche sulle modifiche apportate alla topologia della replica. Nella tabella 30 vengono illustrate le competenze del proprietario
della topologia dei siti.
Tabella 30 Responsabilità del proprietario della topologia dei siti
Ruolo
Competenza
Controllo delle modifiche della topologia dei siti
Quando viene modificata la connettività di rete, il
proprietario apporta le modifiche corrispondenti
alla topologia dei siti.
Spostamento dei domain controller da un sito
all'altro
Se l'indirizzo IP di un domain controller cambia,
e in conseguenza di ciò il domain controller viene
inserito nella subnet di un altro sito, oppure se la
subnet viene spostata in un altro sito, è
necessario trasferire manualmente il domain
controller nel nuovo sito.
Legame con il gruppo di rete
Il proprietario riceve e conserva le informazioni
sulle connessioni e sui router che incidono sulla
topologia dei siti.
• Per impostare i costi dei collegamenti di sito in
modo economico, il proprietario è a conoscenza
delle questioni in merito alla velocità e alla
capacità della rete che influenzano la topologia
dei siti.
•Inoltre il proprietario gestisce un elenco degli
indirizzi delle subnet, delle subnet mask e la
posizione di ognuno.
Progettazione ottimale della topologia dei siti
In questo documento non è incluso un modello specifico ma sono fornite alcune linee guida per la creazione della topologia
ottimale dei siti.
•
Delegare l'autorità per la gestione della topologia dei siti al proprietario della topologia stessa.
•
Utilizzare la configurazione predefinita per la replica tra siti, laddove possibile. In tale configurazione rientra quanto
segue:
o Non disattivare la verifica di coerenza delle informazioni (KCC, Knowledge Consistency Checker).
o Non disattivare la transitività dei collegamenti di sito.
o Non specificare i server bridgehead.
o Lasciare la pianificazione della replica aperta il più possibile.
•
Nell'ambito della topologia, calcolare la latenza prevista della replica tra siti.
Per ulteriori informazioni sulla replica, vedere The Active Directory Branch Office Planning Guide, disponibile on-line all'indirizzo
http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/branchoffice/default.asp.
Di seguito sono riportate le linee guida per la progettazione ottimale dei collegamenti di sito:
•
•
Associare i collegamenti di sito ai collegamenti WAN.
Assicurarsi che nessun sito sia direttamente connesso a più di 20 siti.
Questa condizione può verificarsi in deployment di tipo hub e spoke di grandi dimensioni, dove la maggior parte dei
siti è rappresentata da filiali che comunicano con un sito hub centralizzato. Se esiste tale condizione e vi sono più di
20 collegamenti di sito tra il sito hub e le filiali, è possibile suddividere il sito hub in più siti per fornire ulteriori server
bridgehead in grado di gestire il volume di replica. In ogni dominio di un sito è attivo un solo server bridgehead.
Quindi, se un sito dispone di più di 20 collegamenti di sito, i server bridgehead possono diventare sovraccarichi.
Processo di progettazione della topologia dei siti
Per progettare la topologia ottimale, eseguire le seguenti operazioni nell'ordine specificato:
1.
2.
3.
4.
5.
Creare la mappa delle località.
Posizionare i domain controller nelle località.
Creare i siti in base alle località.
Collegare i siti con i collegamenti di sito.
Pianificare la capacità dei domain controller.
Nella figura 35 viene illustrato il processo di progettazione della topologia dei siti.
Figura 35 Flusso delle attività per il processo di progettazione della topologia dei siti
Creazione della mappa delle località
La mappa delle località determina la posizione degli utenti e le località più adatte alla replica di altre località. Secondo la
metodologia ottimale, i siti Active Directory devono essere associati alle località dei segmenti LAN della rete. Per creare la
mappa delle località:
1.
Creare una mappa che abbracci tutte le località fisiche della foresta connesse mediante collegamenti di tipo LAN o
con velocità superiore.
Per località fisica si intende un gruppo di utenti con connettività interna di 10 Mbps o superiore.
2.
3.
Per ogni località stabilire:
o Il numero di utenti.
o Il numero di workstation.
o L'elenco delle subnet IP locali.
Aggiungere alla mappa le connessioni di rete WAN indicando:
o La velocità WAN tra tutte le località.
o L'utilizzo attuale del collegamento WAN.
Nella figura 36 viene illustrato un esempio di mappa delle località. Per ogni località è indicato il numero di utenti, il numero di
workstation e gli indirizzi IP delle subnet di rete presenti. Per ogni connessione di rete vengono indicate la velocità WAN e la
percentuale o la larghezza di banda utilizzata.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 36 Mappa delle località con segmenti LAN e collegamenti WAN
Posizionamento dei domain controller nelle località
Assieme ai proprietari dei domini, il proprietario della topologia dei siti determina la posizione dei domain controller del
dominio radice della foresta e dei domini regionali. Posizionare i domain controller nelle località cosicché, se il collegamento
WAN non funziona, gli utenti possano comunque essere autenticati localmente.
Iniziare la valutazione delle località in base al posizionamento dei domain controller nei siti hub. Dopo aver finito di aggiungere
i domain controller a tutti i siti hub, passare alle località satellite. È possibile evitare di aggiungere domain controller alle
località più piccole se:
•
La località non contiene un numero sufficiente di utenti e di workstation per giustificare la presenza di un domain
controller.
•
Non è possibile garantire l'integrità fisica del domain controller.
Nella figura 37 viene illustrata una mappa di tutti i siti con i domini significativi per ognuno di essi.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Figura 37 Domini presenti in un insieme di siti
Posizionamento dei domain controller nella radice della foresta
Per ogni sito hub, posizionare un domain controller nel dominio radice della foresta. Per ogni località satellite, valutare
l'eventuale necessità di un domain controller nella radice della foresta. Tenere presente che per l'accesso di un client a una
risorsa inclusa in un dominio diverso dal proprio, è necessaria una comunicazione con un domain controller della radice della
foresta. Per questo motivo, una località con domain controller di due o più domini regionali deve includere anche un domain
controller della radice della foresta.
Posizionamento dei domain controller regionali
Posizionare in una località un domain controller per i domini regionali qualora gli utenti di tale località debbano poter accedere
anche quando il collegamento WAN non è in funzione. Se il domain controller locale non funziona, gli utenti locali possono
accedere tramite il collegamento WAN. Per migliorare le prestazioni dell'accesso nel caso in cui non funzioni l'unico domain
controller presente, è consigliabile aggiungere un secondo domain controller.
Posizionamento dei domain controller primari
Ogni dominio include un domain controller a cui viene affidato il compito di svolgere alcune operazioni specifiche (Operations
Master), tra le quali anche quella di emulare un domain controller primario di un dominio Windows NT. Il domain controller
primario va posizionato in una località che:
•
•
Sia ben connessa agli altri siti.
Contenga un numero elevato di utenti del dominio.
Il sito in cui viene posizionato il domain controller primario diventa il sito primario per tale dominio.
Posizionamento dei server contenenti il catalogo globale
Per accedere ai domini Active Directory in modalità nativa è necessario almeno un server contenente il catalogo globale. Per
evitare di dover contattare un server contenente il catalogo globale di un sito distante in caso di procedure di accesso e di
ricerche che interessino l'intera foresta, è opportuno designare almeno un domain controller per sito come catalogo globale.
In una progettazione ottimale è necessario che la metà di tutti i domain controller del sito sia ospiti il catalogo globale. Devono
in ogni caso essere presenti almeno due server con questa funzione se il sito include più domain controller. Se si utilizza il
modello di dominio globale unico, è necessario prevedere che tutti i domain controller del dominio globale siano anche server
contenenti il catalogo globale. Dato che il dominio radice della foresta è molto piccolo, è necessaria una limitata quantità di
risorse aggiuntive per rendere tali tutti i domain controller.
Creazione dei siti in base alla località
Ogni località che include un domain controller rappresenta un sito. Per creare un sito:
1.
2.
Assegnare un nome al sito.
Specificare gli indirizzi IP associati al sito.
Non specificare come siti le località prive di domain controller. Invece, associare le subnet di queste località ai siti in
cui si desidera che gli utenti vengano autenticati.
Connessione dei siti mediante i collegamenti di sito
La replica tra siti si verifica sulla base delle impostazioni definite dagli amministratori dei siti per gli oggetti collegamento di
sito creati in Active Directory. Ogni oggetto collegamento di sito rappresenta la connessione WAN tra due o più siti.
Per controllare come avviene la replica tra i siti, eseguire le operazioni seguenti:
1.
2.
3.
Connettere i siti mediante i collegamenti di sito per definire lo schema di connessione delle località.
Denominare i collegamenti di sito <nome_del_sito1>-<nome_del_sito2>.
Impostare i parametri dei collegamenti di sito:
o Costo
o Pianificazione
o Intervallo
Nota Se più siti dispongono della stessa connettività e disponibilità l'uno verso l'altro, è possibile connetterli tra loro con lo
stesso collegamento di sito.
Nella figura 38 viene illustrata una mappa in cui sono indicati i collegamenti di sito e le velocità WAN.
Figura 38 Mappa della rete dei collegamenti di sito e delle velocità WAN
Impostazione del costo
Per determinare i costi dei collegamenti di sito, eseguire le operazioni seguenti:
1.
2.
3.
Controllare la velocità del collegamento.
Creare una tabella contenente la velocità di connessione di ogni collegamento di sito.
Utilizzare la tabella 31 per calcolare il costo di ogni collegamento di sito.
Per calcolare il fattore di costo relativo dei collegamenti di sito in modo che sia correlato alla larghezza di banda
disponibile, utilizzare la formula seguente:
Tabella 31 Impostazione dei costi dei collegamenti di sito in base alle velocità WAN
Larghezza banda disponibile
(kilobit/secondo)
Costo
9,6
1042
19,2
798
38,4
644
56
586
64
567
128
486
256
425
512
378
1024
340
2048
309
4096
283
Questi costi non rispecchiano eventuali differenze in merito all'affidabilità dei collegamenti di rete. Quindi, per la replica è
consigliabile non utilizzare collegamenti poco affidabili. Impostare costi maggiori nel caso di collegamenti di rete soggetti a
prestazioni scadenti.
Quando un collegamento di sito è inattivo, il failover della replica può essere previsto e controllato grazie all'impostazione dei
costi dei collegamenti di sito. Nella figura 39 viene illustrato come utilizzare i costi dei collegamenti di sito per calcolare il costo
relativo del collegamento di due siti qualsiasi della topologia.
Figura 39 Mappa dei siti indicante i costi dei collegamenti
Impostazione della pianificazione
Mediante la pianificazione di una finestra temporale per la replica, il proprietario della topologia dei siti determina la
disponibilità dei collegamenti di sito per l'esecuzione della replica. Tuttavia, se un ciclo di replica è ancora in corso al termine
del periodo pianificato, esso verrà eseguito fino al suo completamento, anche se la finestra temporale prevista è ormai chiusa.
Controllare la disponibilità dei collegamenti di sito impostandone la pianificazione. È possibile utilizzare la pianificazione
predefinita (disponibilità al 100 percento) per la maggior parte dei collegamenti, ma è consigliabile bloccare il traffico di replica
durante le ore di maggior lavoro per i collegamenti con determinate località remote. Con il blocco della replica, da un lato
viene data priorità ad altro traffico, dall'altro si aumenta la latenza della replica.
Quando la replica tra due siti interessa più collegamenti di sito, l'intersezione delle pianificazioni di tutti i collegamenti
significativi determina la pianificazione della connessione tra questi due siti. Inoltre, se le pianificazioni di ogni collegamento
non combaciano mai, la replica non può mai verificarsi.
Impostazione dell'intervallo
All'interno della finestra temporale pianificata per la replica, l'intervallo determina la frequenza con cui i domain controller
richiedono l'elenco delle modifiche ai partner di replica.
Nel corso di ogni finestra temporale pianificata per la replica, decidere l'intervallo di tempo che determina la frequenza della
replica. Prendere in considerazione i criteri seguenti:
•
•
Un piccolo intervallo diminuisce la latenza ma aumenta la quantità di traffico WAN.
Per mantenere aggiornate le partizioni della directory dei domini, è preferibile una latenza bassa.
Calcolo della latenza massima
Se si applica una strategia di replica di tipo ”store and forward” non è facile determinare esattamente il tempo necessario per
replicare l'aggiornamento della directory in ogni domain controller. Per calcolare una stima accettabile anche se non accurata
della latenza massima, eseguire le operazioni seguenti:
1.
Creare una tabella con tutti i siti hub della rete. La tabella deve essere simile a quella seguente (tabella 32).
Tabella 32 Latenza della replica tra siti hub
Seattle
Seattle
Vancouver
Boston
0,25
Boston
0,25
Vancouver
0,25
Milano
2.
3.
Milano
0,25
La latenza media peggiore all'interno di un sito è valutata in 15 minuti.
In base alla pianificazione della replica, determinare la massima latenza possibile della replica per ogni collegamento
di sito tra due siti hub.
Ad esempio, se la replica si verifica tra Seattle e Boston per un'ora al giorno, il ritardo massimo della replica tra
questi due siti è di 23 ore. Se il ritardo della replica tra Boston e Seattle è il maggiore tra quelli pianificati tra tutti i
siti hub, la latenza massima tra tutti gli hub è di 23 ore.
4.
Per ogni sito hub, creare una tabella delle latenze massime tra il sito hub e uno dei suoi siti satellite.
Ad esempio, se la replica si verifica tra Boston e Bar Harbor ogni quattro ore e si tratta del maggiore ritardo della
replica tra Boston e uno dei suoi siti, la latenza massima tra l'hub di Boston e i suoi satelliti è di quattro ore.
5.
Combinare le latenze massime per stabilire la latenza massima per l'intera rete.
Ad esempio, se la latenza massima tra Milano e il suo sito satellite di Siviglia è di un giorno, la latenza massima della
replica per questo insieme di collegamenti è di 52 ore (4+24+24).
Valutare la latenza massima della replica e apportare le eventuali modifiche alla pianificazione della stessa.
Pianificazione delle capacità dei domain controller
Le operazioni che seguono originano carichi di lavoro specifici nei domain controller:
•
•
•
•
•
Accesso di utenti e workstation
Operazioni di ricerca nella directory
Replica
Master operations
Altri servizi in esecuzione nei domain controller
Le procedure di accesso degli utenti e delle workstation seguite da ricerche nella directory incidono molto sulle prestazioni dei
domain controller.
Per determinare le prestazioni dei domain controller generalmente non si fa riferimento alla dimensione del dominio, bensì si
tengono in considerazione i modelli di utilizzo e il numero di utenti che accedono a un domain controller in un sito specifico.
Nella tabella 33 viene illustrato in quale modo i servizi incidono sulle prestazioni dei domain controller.
Tabella 33 Incidenza dei servizi sulle prestazioni dei domain controller
Operazione
Servizio
Incidenza sulle prestazioni
Accesso degli utenti
Accesso interattivo di utenti,
accesso degli utenti alla rete,
accesso batch degli utenti
Elevata
Accesso delle workstation
Processo di avvio delle
workstation
Media
Operazione di ricerca
Operazioni di ricerca, ricerche
LDAP
Dipende dall'utilizzo
Replica con 1-10 partner
Replica Active Directory
Bassa - Media
Replica con più di 10 partner
Replica Active Directory
Elevata
Master operation PDC
Inoltro delle modifiche delle
password, inoltro degli accessi
Elevata
Master operation infrastruttura
Convalida dei collegamenti agli
oggetti spostati
Bassa
Master operation pool RID
Distribuzione di pool RID
(Relative IDentifier) ai domain
controller del dominio
Bassa
KCC con meno di 200 siti
Calcolo della topologia della
replica
Bassa - Media
KCC con più di 200 siti
Calcolo della topologia della
replica
Elevata
Servizio del catalogo globale
Ricerche dell'appartenenza ai
gruppi universali, ricerche al
livello dell'intera foresta
Bassa - Elevata (con Exchange
2000)
Servizi infrastrutturali
DNS, WINS, DHCP
Media
Altri servizi
File e stampa, operazioni di
database
Dipende dall'utilizzo
Requisiti per il processore
Nella tabella 34 viene illustrata la dimensione dei domain controller e dei servizi che possono essere caricati.
Tabella 34 Pianificazione delle capacità dei domain controller
Domain
controller
Catalogo
globale
DC dedicato
Server/Advanced
Server
< 100
Uno con
monoprocessore
PIII 500, 512 MB
Il domain
controller è un
catalogo globale.
No
Server
101 – 500
Uno con
monoprocessore
PIII 500, 512 MB
Il domain
controller è un
catalogo globale.
Sì
Server
500 – 1.000
Uno con doppio
processore PIII
500, 1 GB
Il domain
controller è un
catalogo globale.
Sì
Server
1.000 – 10.000
Due con quattro
processori PIII
XEON, 2 GB
Entrambi i
domain controller
sono cataloghi
globali.
Sì
Advanced Server
> 10.000 utenti
Uno con quattro
processori PIII
XEON, 2 GB per
ogni 5.000 utenti
Un catalogo
globale ogni due
domain controller
con almeno due
cataloghi globali.
Sì
Advanced Server
Utenti del sito
Nota Di seguito vengono riportate le linee guida per la capacità hardware ottimale dei domain controller:
•
•
•
Da 100 a 200 siti, utilizzare hardware multiprocessore.
Per più di 200 siti, consultare la documentazione Microsoft per la progettazione di reti con molte filiali.
Per siti connessi a 10 o più siti, utilizzare hardware multiprocessore.
•
Per domini con più di 50.000 utenti, utilizzare un server con quattro processori PIII XEON con 2 GB di memoria per il
server che svolge il compito di PDC.
Questa tabella costituisce un punto di partenza per il dimensionamento dei domain controller. La scelta dell'hardware dipende
dal tipo di utilizzo. Se è necessario definire con più precisione le capacità hardware o se si utilizza Exchange 2000, è
consigliabile:
1.
Scaricare ed eseguire ADSizer.
È possibile scaricare ADSizer all'indirizzo http://www.microsoft.com/windows2000/downloads/tools/sizer/default.asp.
2.
Verificare la configurazione hardware mediante test di laboratorio prima di eseguire il deployment.
Requisiti per i dischi
I domain controller e i server che ospitano il catalogo globale tendono ad utilizzare grandi quantità di spazio per l'archiviazione
dei dati nel database Active Directory. Determinare lo spazio necessario per il database Active Directory in base alle
informazioni incluse nella tabella 35.
Tabella 35 Requisiti di spazio su disco per il database Active Directory
Server
Spazio da riservare per il database Active Directory
Domain
controller
0,4 GB di spazio ogni 1.000 utenti.
Server che
ospitano il
catalogo
globale
Ad esempio, in una foresta con due domini da 10.000 utenti, tutti i domain controller necessitano di 4 GB di spazio. Tutti i
server che ospitano il catalogo globale richiedono 6 GB di spazio.
Questi requisiti rappresentano stime approssimative. Per una valutazione più precisa dei requisiti di spazio, scaricare ed
eseguire ADSizer, disponibile on-line all'indirizzo: http://www.microsoft.com/windows2000/downloads/tools/sizer/default.asp.
Requisiti per la configurazione dei dischi
Un domain controller necessita di spazio adeguato sui dischi per il sistema operativo, i file di log, il database e il volume di
sistema (SYSVOL). Per i domain controller di siti con meno di 10.000 utenti, questi quattro componenti possono risiedere in un
singolo array RAID 1 (dischi in modalità “mirror”), che offre una protezione adeguata in caso di errore del singolo disco.
Se con il tempo si riscontra che un calo delle prestazioni del domain controller legato alle operazioni di I/O sul disco, è
possibile migliorarne le performance aggiungendo ulteriore memoria (fino a 2 GB), evitando così di dover spostare il sistema
operativo, il database o i file di log in altri sistemi RAID 1.
Per i domain controller di siti con più di 10.000 utenti, utilizzare array RAID 1 distinti come indicato nella tabella 36.
Tabella 36 Pianificazione delle capacità dei dischi dei domain controller
Componente del servizio di
directory
Operazioni eseguite
Sistema RAID
Sistema operativo
Operazioni di lettura e scrittura
RAID 1
File di log
Principalmente operazioni di
scrittura
RAID 1
Database e SYSVOL
Principalmente operazioni di
lettura
RAID 1 o RAID 0+1
Implementazione della progettazione
Dopo aver completato tutte le attività previste dal processo di progettazione, implementare il progetto eseguendo dei test di
laboratorio, quindi attuare il progetto nell'ambiente di produzione. Nella guida complementare Best Practice Active Directory™
Deployment for NOS Environments sono incluse informazioni utili per facilitare il processo di implementazione.
Parte III - Fogli di lavoro
Fogli di lavoro relativi al numero di foreste dell'organizzazione
Dopo aver completato tutte le attività previste dal processo di progettazione, implementare il progetto eseguendo test di
laboratorio e test in ambienti pilota, quindi attuare il progetto nell'ambiente di produzione. Nella guida complementare Best
Practice Active Directory™ Deployment for Managing Windows Networks sono incluse informazioni utili per l'implementazione.
I fogli di lavoro che seguono corrispondono ai titoli della presente guida. Essi sono stati costruiti per facilitare la raccolta e
l'organizzazione delle informazioni necessarie per personalizzare il deployment di Active Directory nella propria organizzazione.
Mano a mano che si procede nella consultazione di questo documento e nella conduzione delle sessioni di pianificazione, è
necessario compilare i fogli di lavoro corrispondenti. Questi fogli di lavoro costituiscono nel loro insieme la parte fondamentale
della pianificazione del progetto di deployment di Active Directory nella propria organizzazione.
Foglio di lavoro - Team di progettazione del numero di foreste
Indica i singoli partecipanti al comitato incaricato di determinare il numero di foreste Active Directory che l'organizzazione
intende progettare e di cui desidera eseguire il deployment.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Possibili fornitori del servizio di directory
Segnalare in questo foglio di lavoro le divisioni aziendali che potrebbero fornire il servizio di directory e che hanno partecipato
alla progettazione delle foreste Active Directory.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Elencare tutte le organizzazioni candidate a diventare fornitrici del servizio di directory e includere il nome della persona da
contattare. Se l'organizzazione ha già eseguito il deployment di Active Directory, specificare il nome della foresta esistente.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Giustificazione della progettazione delle foreste
Nel foglio di lavoro che segue va segnalata la giustificazione logica per la progettazione di ogni possibile foresta indicata nel
foglio di lavoro precedente. Creare un foglio di lavoro per ogni possibile foresta dell'organizzazione.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Foreste proposte
Il foglio di lavoro che segue elenca le foreste che l'organizzazione ha proposto di realizzare.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Fogli di lavoro per la progettazione delle foreste Active Directory
Completare un insieme dei restanti fogli di lavoro per ogni foresta identificata nel foglio di lavoro Numero di foreste. Per ogni
foresta indicata, inoltrare questo documento alla persona di riferimento per la foresta, che a sua volta è tenuta a completare
gli altri fogli di lavoro inclusi in questa guida per finalizzare la progettazione di Active Directory per la foresta.
Foglio di lavoro - Team di progettazione della foresta
Nei fogli di lavoro che seguono vengono indicati il team di pianificazione e i tecnologi responsabili della progettazione dei
domini Active Directory della propria foresta.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Completare la tabella identificando i tecnologi e i membri del team responsabili della progettazione di Active Directory della
propria foresta. Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Amministrazione del dominio radice della foresta
Il foglio di lavoro che segue consente di identificare gli amministratori del dominio radice della foresta.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Architettura del dominio radice della foresta
Il foglio di lavoro che segue consente di identificare lo schema di denominazione per il dominio radice della foresta.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Identificazione delle regioni
Il foglio di lavoro che segue consente di identificare le regioni della foresta.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Foglio di lavoro - Architettura proposta per il dominio
Il foglio di lavoro che segue consente di identificare il modello adottato per i domini della foresta.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Inventario dei domini MUD di Windows NT
Il foglio di lavoro che segue consente di identificare i domini MUD di Windows NT esistenti nella foresta.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Per ogni dominio MUD esistente nella foresta copiare e completare il foglio di lavoro "Riferimento rapido". Aggiungere o
rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Informazioni sui domini MUD
Per ogni riga del precedente foglio di lavoro, copiare e completare il foglio di lavoro che segue definendo i dettagli e la
giustificazione della strategia di migrazione adottata.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Associazione dei domini di risorse Windows NT
Identificare ogni dominio di risorse esistente nella foresta completando il foglio di lavoro che segue.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Inventario del servizio DNS esistente
Se nella foresta è già presente un servizio DNS, compilare tutti i fogli di lavoro di questa sezione. In caso contrario, ignorare i
fogli di lavoro di questa sezione relativi all'inventario.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Informazioni sui client DNS
Rispondere alle domande seguenti per descrivere i computer client DNS della foresta.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Configurazione dei client DNS
Creare uno schema che corrisponda al modello del client.
Foglio di lavoro - Architettura del server DNS
Creare uno schema che corrisponda al servizio DNS per il modello Active Directory (DNS con i percorsi predefiniti, DNS con
inoltro e/o soluzione DNS/DHCP integrata).
Foglio di lavoro - Team di progettazione delle unità organizzative
Il foglio di lavoro che segue consente di identificare i singoli partecipanti al team di progettazione delle unità organizzative del
dominio.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Foglio di lavoro - Identificazione delle unità organizzative di ogni dominio
Il foglio di lavoro che segue consente di identificare le unità organizzative di ogni dominio della foresta. Compilare il foglio di
lavoro che segue indicando le unità organizzative di ogni dominio.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Foglio di lavoro - Team di progettazione della topologia dei siti
Il foglio di lavoro che segue consente di identificare i membri del team di progettazione della topologia dei siti.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Località geografiche e collegamenti per le comunicazioni
Riepilogare in una mappa geografica o organizzativa le località e i collegamenti. Includere il numero di utenti di ogni località e
la velocità dei collegamenti.
Foglio di lavoro - Località geografiche e collegamenti
Questo foglio di lavoro consente di identificare ogni località e quelle direttamente connesse ad ognuna di esse, il tipo di
connessione e la capacità di rete effettivamente disponibile (ovvero, quella che rimane dopo aver calcolato tutto l’altro traffico
di rete).
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Posizionamento dei domain controller
Nei fogli di lavoro che seguono viene descritto il posizionamento dei domain controller della foresta, pianificati ed esistenti.
Nella colonna Nome località indicare tutte le località geografiche. Per ogni località indicare inoltre i nomi dei domini del sito e il
numero di utenti, i domain controller e i server che ospitano il catalogo globale utilizzati come domain controller nel sito.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Associazione dei siti alle località e alle subnet
Nel foglio di lavoro che segue è possibile associare i siti alle rispettive località e subnet.
Se il browser in uso non supporta frame non ancorati (inline), fare clic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Foglio di lavoro - Parametri dei collegamenti di sito
Nel foglio di lavoro che segue vengono descritti il costo, la pianificazione e l'intervallo di replica associati ad ogni collegamento
di sito.
Se il browser in uso non supporta frame non ancorati (inline), farelic qui per la visualizzazione in una pagina distinta.
Aggiungere o rimuovere righe dalla tabella per personalizzare il modulo per la propria organizzazione.
Declinazione di responsabilità per la versione Beta
Questa documentazione consiste in una prima versione della documentazione finale, che potrà subire significative modifiche
prima del rilascio commerciale della versione finale. Si tratta di informazioni riservate e di proprietà di Microsoft Corporation.
Viene divulgata in conformità a un accordo di non divulgazione tra il destinatario e Microsoft. Questo documento è stato
realizzato esclusivamente per scopi informativi e Microsoft esclude ogni garanzia espressa o implicita in questo documento. Le
informazioni qui contenute, inclusi i riferimenti a URL e a altri siti Web, sono soggette a modifiche senza preavviso. L'utente
utilizza il documento a proprio rischio. Se non specificato diversamente, ogni riferimento a società, organizzazioni, prodotti,
persone e fatti è puramente casuale. Nessuna associazione con società, organizzazioni, prodotti, persone o eventi reali può
pertanto esservi desunta. Il rispetto di tutte le applicabili leggi in materia di copyright è esclusivamente a carico dell'utente.
Fermi restando tutti i diritti coperti da copyright, nessuna parte di questo documento potrà comunque essere riprodotta o
inserita in un sistema di riproduzione o trasmessa in qualsiasi forma e con qualsiasi mezzo (in formato elettronico, meccanico,
su fotocopia, come registrazione o altro) per qualsiasi scopo, senza il permesso scritto di Microsoft Corporation.