Active Directory supporta una tipologia di replicazione delle informazioni contenute nel suo database denominata Multi-Master. Con questo termine si vuol semplicemente affermare che nessun Domain Controller è “primario” (ossia, usando un termine forse improprio, “proprietario dei dati”), ma, al contrario, una qualunque informazione può essere modificata su qualunque DC per poi essere propagata a tutti gli altri secondo un preciso schema logico di connessioni.
Fermo restando la validità un meccanismo di replicazione siffatto, può non apparire altrettanto evidente che esso possa condurre a conflitti sull’integrità dei dati, qualora una modifica fosse seguita “accidentalmente” e contemporaneamente su più DC allo stesso istante. Ovviamente Windows Server 2003 ha previsto casi del genere e gestisce tali situazioni mediante l’adozione di un algoritmo che replica solo la modifica effettuata sul DC con data più recente, scartando di conseguenza tutte le altre.
Questo approccio, sebbene possa essere ritenuto accettabile in molti casi, potrebbe non essere adeguato in altre situazioni. Per prevenire conflitti in aggiornamento sugli oggetti vitali all’infrastruttura, Active Directory adotta un modello Single-Master per la modifica di alcune informazioni. In questa modalità, un solo DC nell’intera directory può essere utilizzato per gli aggiornamenti. Su questo principio si basa, ad esempio, il Primary Domain Controller di un Dominio Windows NT 4.0, in quanto è l’unico responsabile della modifica dei dati nel proprio dominio.
Windows Server 2003 estende il modello Single-Master, mediante il quale si gestivano gli aggiornamenti in NT, ad altri ruoli e consente di trasferirli su qualsiasi DC dell’infrastruttura. Siccome i ruoli non sono legati ad un particolare DC, essi sono indicati col termine Flexible Single Master Operation (FSMO) role.
I ruoli FSMO
Attualmente Windows Server prevede cinque ruoli FSMO dei quali 2 riferiti specificamente alle foreste e 3 ai domini:
Ruoli per le foreste:
- Schema Master
- Master dei nomi di dominio
Ruoli per i domini:
- RID Master
- Emulatore PDC
- Master Infrastructure
Per quanto detto in precedenza, risulta abbastanza ovvio che, per ognuno di questi ruoli, può esistere soltanto un server che lo ricopra.
Esistono diversi metodi per stabilire quali siano le macchine che ricoprono ciascuno di questi ruoli ed uno di questi consiste nell’utilizzo dell’utility netdom fornito nell’Administration Tools Pack per Windows Server 2003.
Un esempio classico di utilizzo di questo tool è il seguente: netdom query fsmo, che restituisce un risultato come indica la figura 1.
Figura 1 – Risultato del comando NETDOM QUERY FSMO
Descriviamoli brevemente:
Schema Master
Lo Schema Master è l’unico DC in grado di apportare modifiche allo Schema di AD. Una volta che lo Schema è stato modificato, esso viene replicato dallo Schema Master agli altri DC nella Directory.
Master dei Nomi di Dominio
Il Domain Naming Master è il DC responsabile delle modifiche al Domain Namespace della Directory. Questo DC è l’unico in grado di aggiungere o rimuovere un dominio da Active Directory oltre ad aggiungere o rimuovere cross-reference a domini di altre Directory.
RID Master
Il RID Master è il DC responsabile della gestione delle richieste al RID Pool operate da tutti i DC appartenenti ad dominio. E’ inoltre responsabile delle operazioni di “spostamento” di oggetti tra domini differenti.
Cerchiamo di capire brevemente cos’è un RID Pool e a che serve il ruolo RID Master. Quando un DC crea un security principal object (tipicamente, un nuovo utente o un nuovo gruppo) ad esso viene associato un Security ID (SID) univoco nel dominio. Tale SID costituito da due parti:
- un Domain SID (lo stesso per tutti i SID creati nel dominio)
- un Relative ID (RID) (univoco per ogni security principal SID creato nel dominio)
Ogni DC di un dominio ha a disposizione un pool di RID (costituito da 512 elementi) per consentirgli la creazione di un certo quantitativo di security principal object. Quando il numero di RID disponibili ad un DC scende sotto una certa soglia, il DC è costretto a generare una richiesta di RID addizionali al RID Master del dominio. Quest’ultimo risponde a tale richiesta recuperando RID dal pool dei RID di dominio non ancora assegnati e li associa al pool dei RID del DC che ne ha fatto la richiesta. Tuttavia, è interessante ricordare che il DC non utilizzerà il nuovo insieme di SID ottenuti dal RID Master sino a quando non avrà esaurito quelli che aveva in precedenza a disposizione.
Emulatore PDC
In un dominio Windows 2000, o superiore, il PDC Emulator ha le seguenti funzioni:
- I cambiamenti di password eseguiti da un DC sono replicati in prima istanza sul PDC Emulator
- Gestione degli account locked
- Le mancate autenticazioni ad un dato DC a causa di password errata, sono riverificate sul PDC Emulator prima di ritornare un messaggio di login non consentito all’utente
- Funzionalità di Primary Domain Controller (PDC) per client pre-Windows 2000
- Funzionalità di time service (necessario al protocollo Kerberos) nel dominio di pertinenza
In particolare, l’emulatore PDC, in ambienti native-mode si preoccupa di riprocessare le richieste di autenticazione fallite in precedenza sugli altri DC.
Il ruolo appena descritto è probabilmente quello maggiormente coinvolto nelle attività di una rete aziendale (soprattutto se parliamo di ambienti misti, dove risultano essere presenti anche macchine NT) e pertanto è quello che “conviene” tenere maggiormente sotto controllo. A questo proposito, quindi, è bene sempre accertarsi di eseguire un ruolo siffatto su macchine performanti e dotate di hardware fault tolerant per evitare “inutili” disagi.
Master Infrastructure
Il Master Infrastructure assicura la consistenza degli oggetti tra il dominio ed i domini remoti. Volendo semplificare, potremmo anche dire che è l’unico server che tiene traccia di oggetti contenuti all’interno di un’altra directory, ma che risultano essere referenziati anche in quella corrente.
Sappiamo tutti che se un oggetto viene referenziato da un dominio diverso da quello di appartenenza, questa referenza contiene:
- Globally Unique IDentifier (GUID)
- Security IDentifier (SID)
- Distinguished Name (DN) dell’oggetto
Se l’oggetto referenziato viene spostato, il Master Infrastructure si preoccupa di aggiornare i SID e i DN nelle referenze cross-domain a quell’oggetto. Per semplicità: se aggiungiamo un utente appartenente ad un dominio all’interno di un gruppo di sicurezza facente parte di un dominio remoto, il Master Infrastructure si preoccupa di supervisionare l’operazione accertandosi che avvenga nella maniera corretta.
Un ruolo siffatto deve essere attivato necessariamente su un DC che non sia Global Catalog (GC). La motivazione, sebbene apparentemente “strana”, è semplice: se questo ruolo fosse ospitato da un server GC, esso non aggiornerebbe le informazioni sulle relazioni cross-domain a causa del fatto che esso non contiene alcuna referenza ad oggetti che non possiede. Questo perché, lo ricordiamo, un GC possiede solamente una replica parziale degli oggetti della foresta. Tuttavia, nel caso in cui tutti i DC siano allo stesso tempo GC o ci si trovi in presenza di un unico dominio, tale considerazione è superflua.
Problemi con i Server FSMO
La mancata disponibilità di uno dei ruoli sopra definiti, può creare, ovviamente, una serie di disservizi legati alle rispettive funzionalità di ognuno di essi. In particolare:
- Schema Master: non è possibile modificare lo schema di foresta, un’operazione eseguita di rado
- Domain Naming Master: non è possibile aggiungere e/o togliere domini alla foresta
- RID Master: se il pool di 512 RID visti in precedenza ed assegnati di default a ciascun DC viene esaurito, non è più possibile aggiungere oggetti (utenze, gruppi, ecc.) da quel DC. In alternativa è possibile eseguire tale operazione da un altro DC
- PDC Emulator: le implicazioni sono diverse a seconda che si tratti di ambiente mixed-mode o native-mode e rivestono per lo più il reset di password, il logon degli utenti, il ripristino di account in stato locked, ecc
- Master Infrastructure: possono verificarsi problemi riguardanti le attività amministrative sui gruppi (inserimenti o rinomina di utenze) e, in particolare, problemi con i gruppi universali di Windows 2000.
Nel caso di particolari problemi con uno o più ruoli può essere necessario effettuare uno spostamento dei ruoli interessati su altri server. Quest’operazione è meglio conosciuta con il termine seize.
Non ci dilungheremo sullo spostamento dei ruoli FSMO da un server ad un altro, perché la documentazione fornita da Microsoft è certamente esauriente. In questa sede ci limiteremo a dire solo un paio di cose. Innanzitutto va detto che i ruoli FSMO possono essere spostati da un server ad un altro in qualsiasi momento. Gli strumenti per effettuare quest’operazione sono diversi. In particolare, è importante ricordare che tutti i ruoli possono essere trasferiti servendosi della MMC.