Nel nostro esempio abbiamo, nella precedente lezione, installato un unico domain controller (che chiameremo da qui in avanti, per comodità, DC). Potremmo pensare, soprattutto in configurazioni ad alta affidabilità, di installare un secondo domain controller come replica del primo. In questo modo il database di Active Directory Domain Services (AD DS) contenuto in NTDS.DIT e una copia della cartella System Volume, SYSVOL, saranno sempre replicate nel nuovo nodo.
Le strategie in questo caso possono essere molteplici:
- Possiamo installare un DC Replica.
- Possiamo installare un DC come Read Only Domain Controller (RODC) per porre in sola lettura sia NTDS.DIT che SYSVOL.
La replica di queste risorse può essere affidata direttamente ad AD DS replication service e, per quanto riguarda la cartella SYSVOL, si sfruttano invece le potenzialità del Distribuited File System DFS.
Facciamo un breve esempio per capire meglio di cosa stiamo parlando. Sempre dall’interfaccia del Server Manager, sul nuovo server che vogliamo promuovere come replica, andiamo ad installare il ruolo di Domain Controller come visto nella lezione precedente.
Dopo i primi step di installazione passiamo alla promozione del server come domain controller:
Dal nuovo pannello scegliamo di installare il nuovo server all'interno di un dominio esistente
Selezioniamo l’opzione Controller di dominio di sola lettura, che consente migliori garanzie in termini di sicurezza per quei nodi che sono difficilmente controllabili, inseriamo una password per il DSRM e proseguiamo nel processo di installazione.
Scegliamo con attenzione quali sono le funzionalità che devono essere attive nel nostro server di replica:
Nelle schermate successive ci verranno richieste informazioni relative alla replica e al server di partenza da replicare e ci sarà chiesto se è necessario usare supporti diversi all'installazione IFM (Installa da supporto).
Seguiamo il wizard che ci invita a scegliere le cartelle dove memorizzare database, SYSVOL e log:
Seguiamo gli ultimi passaggi che ci informano, in una sorta di riepilogo, i dati scelti, verificano i prerequisiti e ci invitano ad effettuare l’installazione di tutto ciò che è stato precedentemente selezionato. Al termine del processo di installazione ci verrà chiesto di riavviare il server. Al termine del riavvio avremo il nostro dominio RODC (read only domain controller) a disposizione.
Il global catalog
Un componente importante di Active Directory che merita una sua descrizione a parte, e che avrete sicuramente notato durante tutti i processi di installazione, è il global catalog: un database nel quale sono presenti tutti gli oggetti dei diversi domini presenti all'interno della nostra foresta.
Nello scenario descritto fino ad ora il global catalog non è espresso a pieno. Pensiamo però a scenari in cui siano presenti un dominio A e un dominio B all'interno della stessa foresta. Se avessimo bisogno di conoscere gli oggetti di entrambi i domini dovremmo, appunto, utilizzare il global catalog.
Questo archivio, attraverso una rappresentazione sintetica– non vengono collezionati tutti gli attributi di ogni singolo oggetto –, offre una visione globale di ogni oggetto presente in ogni dominio di ogni foresta.
Gli oggetti sono un insieme di attributi di una risorsa presente in rete: un utente, una stampante, un computer e così via. Per poterli ben gestire, è necessario organizzarli in modo coerente. Nel momento in cui si approccia al mondo delle reti e di Active Directory, sono due i livelli fondamentali che ci consentono di organizzare la nostra rete: logico e fisico.
A livello logico troviamo:
- Organizational Unit: una serie di oggetti del dominio raggruppati tra loro per affinità di interesse (es. stampanti, reparto vendite, etc..).
- Domini: un gruppo di oggetti che condividono un database.
- Alberi di dominio: uno o più domini che condividono un namespace contiguo .
- Foreste di dominio: uno o più alberi di dominio.
A livello fisico invece troviamo:
- Subnet: uno specifico indirizzamento IP con una specifica Subnet Mask.
- Siti: una o più subnet che coesistono tra loro.
Nel nostro caso non siamo interessati a far comunicare diversi domini tra loro, ma potremmo considerare che la nostra PMI ha una sede a Roma e una a Milano, la comunicazione tra queste sedi è possibile proprio tramite la specifica di subnet e siti.
