Migrazione dominio Active Directory: Livelli di funzionalità e ruoli FSMO

Spesso le infrastrutture sono formate da una singola foresta e da un singolo dominio. In queste condizioni è relativamente semplice migrare da una versione meno recente ad una versione più recente del sistema operativo. I problemi iniziano ad essere più complicati quando operiamo in un ambiente Enterprise con differenti domini e con molti servizi legati ad Active Directory.

Iniziamo con una breve introduzione su alcuni dei concetti trattati e sulle infrastrutture utilizzate per eseguire i test.

Active Directory: è un insieme di servizi di rete (Active Directory Domain Services) eseguiti sui Domain Controller. Si basa su un database multimaster che ne permette la distribuzione e la replica tra i Domain Controller garantendo scalabilità e performance.

Foresta: è un insieme di domini che condividono la stessa directory.
foresta-dominio

Dominio: è la porzione di directory che racchiude tutti gli oggetti (computer, utenti, gruppi, etc.)  del singolo domino.  All’attivazione di una nuova struttura Active Directory contestualmente vengono creati una foresta ed un dominio. Successivamente, è possibile aggiungere ulteriori domini ad una foresta esistente. Allo stesso modo, ad un dominio (padre) è possibile aggiungere dei domini figli.
foresta-dominio-figlio

Schema: per definire lo schema credo che la citazione presa da un documento Microsoft sia d’obbligo. The Microsoft Active Directory schema contains formal definitions of every object class that can be created in an Active Directory forest. The schema also contains formal definitions of every attribute that can exist in an Active Directory object.

Naming Context: conosciuto anche con il nome di Directory Partition è la porzione di Active Directory del singolo dominio all’interno della foresta. In una foresta Active Directory esistono differenti partizioni, ognuna con uno scopo ben preciso.

  • Schema Partition: contiene le classi e gli attributi degli oggetti esistenti nella foresta. Ogni Domain Controller nella foresta ne ha una replica.
  • Configuration Partition: contiene alcune configurazioni tra cui la topologia di rete ed è replicata su ogni Domain Controller della foresta.
  •  Domain Partition: contine gli oggetti specifici del dominio (es. computer, utenti, gruppi) ed è replicata su tutti i Domain Controller del dominio.
  •  Application Directory Partition: è una partizione a supporto delle applicazioni e può essere utilizzata dagli sviluppatori per memorizzare dati che si integrano con LDAP. Un classico esempio di partizione applicativa è il servizio DNS integrato in Active Directory. Dal punto di vista delle repliche, la specificità di questa partizione è quella di non dover essere necessariamente replicata su tutti i Domain Controller del dominio e che può essere replicata all’interno della foresta (quindi su differenti domini).

Descrizione infrastruttura
L’articolo si basa su una foresta Windows Server 2003 che contiene due domini.

Foresta: testerlab.local
– Dominio: testerlab.local
— Domain Controller: DC-01-2003 – DC-01-2012
– Dominio: test.local
— Domain Controller: DC-01-2016

Ogni versione di Active Directory è contraddistinta da un valore identificativo conosciuto come livello di funzionalità. In particolare, sono due i livelli di funzionalità. Quello per la foresta e quello per il dominio.
Banalmente, il livello di funzionalità permette di attivare nuove caratteristiche introdotte con le varie versioni del Sistema Operativo. Ma, attenzione, queste caratteristiche saranno attive soltanto se il livello di funzionalità sarà adeguato alla versione necessaria. Quindi, un dominio formato da due Domain Controller con differente Sistema Operativo (es. 2008 e 2012) non potrà rendere disponibili le ultime funzionalità fintanto che dall’infrastruttura non sarà rimosso il Domain Controller 2008 ed aumentato il livello di funzionalità a 2012.

Perché sono importanti questi oggetti e questi valori? L’importanza, come abbiamo visto prima, risiede nel fatto che le funzionalità offerte dal dominio vengono abilitate o meno in base al livello impostato.

Forest Functional Level
Il valore del livello funzionale della foresta è indicato nell’attributo msDS-Behavior-Version
FFL

Domain Functional Level
Il valore del livello funzionale del dominio è indicato nell’attributo msDS-Behavior-Version
DFL

Schema Version
L’attributo objectVersion indica la versione dello schema. Tale attributo è impostato durante la fase di forestprep. Inoltre, lo schema può essere modificato anche da alcuni prodotti che si integrano con Active Directory (Es. Microsoft Exchange).
SV

Questi valori vengono gestiti dalla procedura di migrazione e la loro modifica manuale potrebbe portare a seri problemi dell’infrastruttura.

Prima di addentrarci sui metodi che è possibile utilizzare per visualizzare la versione dei livelli di funzionalità vorrei parlare dei ruoli FSMO.
Come ho scritto nell’introduzione, in una piccola infrastruttura quasi sempre tutti i ruoli sono detenuti da un unico Domain Controller ma in una infrastruttura Enterprise le cose, in genere, cambiano. I ruoli vengono distribuiti su più Domain Controller ed è importante operare nel miglior modo possibile.

Ruoli FSMO
Un altro punto da tenere in considerazione quando ci si appresta alla migrazione di una infrastruttura Active Directory è quello di valutare su quale Domain Controller eseguire le attività, la sequenza temporale e le ripercussioni in termini di utilizzo dei servizi che le nostre attività potrebbero causare.
Per questi motivi è necessario, tra le altre cose, avere ben chiara la topologia fisica e logica dell’infrastruttura su cui ci apprestiamo a lavorare.
I ruoli FSMO sono un punto fondamentale per la scelta della sequenza delle attività da eseguire.
I ruoli FSMO sono cinque e sono così distribuiti:
– Foresta: Domain Naming Master
– Foresta: Schema Master
— Dominio: Infrastructure Master
— Dominio: RID Master
— Dominio: PDC Emulator

Come è possibile vedere dalla seguente screen i ruoli FSM relativi alla foresta sono detenuti (in questo caso) dal Domain Controller Windows Server 2003 che temporalmente si presume sia stato il primo ad essere stato utilizzato nella foresta. Infatti, la prima volta che si crea una infrastruttura Active Directory tutti i ruoli FSMO vengono assegnati all’unico Domain Controller iniziale. In seguito, all’espandersi della foresta, è possibile spostare i ruoli su diversi Domain Controller. Questo per migliorare alcuni aspetti di sicurezza, accessibilità e performance.
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster
forest-fsmo

Nel nostro caso, anche i ruoli FSMO relativi al dominio testerlab.local sono assegnati allo stesso Domain Controller.
Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
testerlab-fsmo

Nel dominio test.local è un Domain Controller Windows Server 2016 a detenere i ruoli. Notare che i ruoli FSMO relativi alla foresta sono sempre detenuti dal Windows Server 2003. Ancora una riconferma…
test-fsmo

Livelli di funzionalità
Dopo questa lunga premessa è giunto il momento di andare a leggere i valori che indicano il livello di funzionalità dell’infrastruttura.
Semplicemente potremmo anche non leggerli, semplicemente potremmo visualizzare l’indicazione del Sistema Operativo. Attività molto semplice ed immediata. Ma lo scopo di questo articolo è quello di mettere in relazione informazioni differenti che possono essere utili sia in fase di analisi che di troubleshooting.

La scelta nell’utilizzare uno strumento piuttosto che un altro dipende dalla familiarità con lo strumento stesso e dalla possibilità di utilizzarlo.

ADSI Edit
Active Directory Service Interfaces Editor  è uno strumento grafico che permette di leggere e modificare gli attributi Active Directory.
Una volta lanciato (AdsiEdit.msc) è necessario connettersi al contesto dei nomi (Naming Context) ed iniziare la ricerca dell’attributo. Purtroppo non è presenta una funzione di ricerca.

Di seguito la screen dell’attributo msDS-Behavior-Version relativo alla foresta ed al dominio testerlab.local. Come si può verificare il valore è per tutti e due ed equivale a quanto riportato nelle  precedenti tabelle.
msDSBehavior-FO-DC-testerlab
Ovviamente, il valore relativo al dominio test.local, che ricordiamo è gestito da un Domain Controller Windows Server 2016, è 7.
msDSBehavior-DC-test

Per quanto riguarda lo schema, il valore è disponibile attraverso l’attributo objctVersion.
schema-objctVersion

Giusto un accenno per ricordare che è anche possibile utilizzare LDP.

PowerSell
Dopo aver visto la parte grafica, che certamente non è la strada più comoda, vediamo come ottenere gli stessi risultati (comodamente) attraverso dei Cmdlet PowerShell.
Il primo Cmdlet è Get-ADForest che se lanciato senza parametri ritorna come output una serie di utilissime informazioni. Nel secondo esempio presente nella seguente screen l’output è filtrato per visualizzare soltanto il valore di ForestMode.
Get-ADForest | fl Name, ForestMode
foresta-livello

Il secondo Cmdlet è Get-ADDomain. Nella successiva screen il risultato relativo ai due domini.
Get-ADDomain | fl Name, DomainMode
domini-livello

Se non si può utilizzare PowerShell (es. Windows Server 2003), lo stesso risultato è possibile ottenerlo utilizzando Dsquery.

Per ottenere il valore relativo alla schema possiamo utilizzare il Cmdlet Get-ADObject.
Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion
schema-version

Per concludere, alcuni semplici, ma spero utili, consigli pratici per chi deve affrontare una migrazione:

  • Verificare che le repliche siano consistenti
  • Eseguire un dcdiag di controllo su ogni Domain Controller
  • Verificare che le share di sistema siano presenti su ogni Domain Controller
  • Verificare la consistenza dei DNS
  • Verificare negli eventi la presenza di eventuali errori o avvisi
  • Verificare i ruoli FSMO al fine di identificare su quale Domain Controller eseguire le attività di migrazione senza correre il rischio di operare con Domain Controller orfani

L’argomento è sicuramente vasto e merita degli approfondimenti, ma come al solito quelli li lascio a voi…

Potrebbero interessare:
Windows Server 2003 migrazione a Windows Server 2012
Windows Server 2012 – Ruoli FSMO
Windows Server 2012 – Metadati Active Directory 1
Windows Server 2012 – Metadati Active Directory 2

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *