Comprendere i ruoli FSMO in Active Directory

Se la tua organizzazione si basa su Microsoft Active Directory, fai affidamento su uno o più controller di dominio per mantenere operative le attività di AD. In superficie, Active Directory sembra funzionare su un modello peer-to-peer in cui ogni controller di dominio (DC) ha l'autorità di creare, modificare ed eliminare oggetti AD. Questo perché ogni controller di dominio detiene una copia scrivibile della partizione del proprio dominio, l'unica eccezione essendo i DC di sola lettura. Una volta che vengono effettuate modifiche o aggiunte, queste vengono sincronizzate con altri DC tramite la replica multi-master. Tuttavia, alcune operazioni fondamentali sono confinate a determinati DC assegnati a ruoli speciali noti come ruoli di Flexible Single Master Operations (FSMO) o ruoli di master operativo.

Di seguito, dettagliamo l'importanza dei ruoli FSMO in Active Directory e condividiamo alcune delle migliori pratiche per garantire una gestione e protezione efficaci.

Introduzione ai ruoli FSMO

FSMO è l'acronimo di Flexible Single Master Operations, un termine che ha origine dal lavoro di Microsoft per affrontare i limiti del modello di replica multi-master in AD. I ruoli FSMO assicurano il funzionamento e la coerenza dell'Active Directory in un dominio Windows assegnando un compito critico specifico a controller designati e fornendo un processo di autorità unico per il cambiamento. Centralizzando queste operazioni all'interno di specifici controller di dominio, i ruoli FSMO aiutano a mantenere l'integrità e la stabilità degli ambienti Active Directory.

Ci sono cinque ruoli FSMO unici. Per impostazione predefinita, quando si crea un dominio Active Directory, tutti i ruoli FSMO sono assegnati al primo controller di dominio nella foresta. Gli amministratori di dominio possono riassegnare i ruoli FSMO ad altri controller di dominio se necessario.

La necessità dei ruoli FSMO

Prima di approfondire i veri e propri ruoli FSMO, è importante comprendere l'architettura multi-master che ne giustifica la necessità.

Modello multi-master vs. Modello single-master

L'architettura di rete iniziale di Microsoft era basata su un Modello a Singolo-Master in cui un singolo server conteneva la copia scrivibile del database con tutti gli account utente e computer. Questo server era l'unico responsabile per l'aggiunta o la modifica del database degli account. Altri server nella rete mantenevano copie in sola lettura del database. Sebbene questi server potessero autenticare gli utenti, non potevano modificare il database. Se il master andava offline o si guastava, non si potevano creare nuovi account e gli account esistenti non potevano essere modificati. Questo creava un unico punto di fallimento.

Per affrontare le limitazioni del Modello a Singolo Master, Microsoft è passata a un Modello Multi-Master in Active Directory (AD), dove ogni domain controller (DC) mantiene una copia scrivibile del database degli account. Questo design garantisce ridondanza e resilienza, poiché le operazioni possono continuare anche se un DC diventa non disponibile. Tuttavia, questo approccio multi-master ha introdotto il potenziale per conflitti, dove diversi DC potrebbero tentare di apportare modifiche in conflitto contemporaneamente. Per prevenire tali incongruenze e mantenere l'integrità e le prestazioni di AD, Microsoft ha introdotto i ruoli Flexible Single Master Operations (FSMO).

Importanza dei ruoli FSMO in AD

Assegnando i ruoli FSMO, Active Directory garantisce che operazioni essenziali—come aggiornamenti allo schema, denominazione del dominio e sincronizzazione dell'orario—siano gestite in modo ordinato e coerente. Se il DC che detiene un ruolo FSMO specifico si guasta, il ruolo può essere trasferito a un altro DC, garantendo continuità. La distribuzione dei ruoli FSMO è fondamentale per mantenere una rete bilanciata ed efficiente, e le organizzazioni possono personalizzare questa distribuzione in base alle loro esigenze specifiche e alle migliori pratiche per prestazioni e ridondanza.

Le 5 FSMO Active Directory Roles spiegate

Active Directory ha cinque ruoli FSMO unici:

• Schema Master (livello foresta)
• Domain Naming Master (livello foresta)
• Master Relative ID (RID) (livello dominio)
• Emulatore del Primary Domain Controller (PDC) (livello di dominio)
• Infrastructure Master (livello di dominio)

Scopriamo di più su ogni ruolo FSMO e la sua specifica funzione all'interno dell'infrastruttura di Active Directory:

Schema Master

Cos'è il ruolo FSMO di schema master?

Il Schema Master è un ruolo FSMO a livello aziendale, quindi esiste un solo Schema Master in una Foresta di Active Directory. Lo schema definisce le classi di oggetti (tipi di oggetti, come utenti, gruppi e computer) e i loro attributi che possono esistere nel database di AD.

Quando e come viene utilizzato lo schema master

A volte, lo schema deve essere modificato, ad esempio, per aggiungere un nuovo tipo di oggetto o attributo richiesto. Per prevenire sovrapposizioni o aggiornamenti in conflitto, solo il DC con il ruolo di Schema Master può elaborare modifiche allo schema di AD. Ogni volta che viene effettuato un aggiornamento dello schema, lo Schema Master assicura che le modifiche vengano replicate in tutti gli altri DC nella foresta.

Se è necessario un aggiornamento dello schema, lo Schema Master deve essere disponibile. Tuttavia, le modifiche allo schema sono relativamente rare nella maggior parte degli ambienti. Le circostanze che possono richiedere una modifica dello schema includono l'aggiornamento di Active Directory, l'integrazione di determinati tipi di software aziendale, l'innalzamento del livello funzionale della foresta e l'aggiornamento del sistema operativo di un DC a una versione superiore rispetto a quella attualmente esistente nella foresta.

Domain Naming Master

Ruoli e responsabilità del Domain Naming Master

Il Domain Naming Master è un ruolo a livello aziendale; esiste un solo Domain Naming Master in una Foresta di Active Directory. È l'unico DC in grado di aggiungere nuovi domini e partizioni di applicazione alla foresta o rimuovere quelli esistenti dalla foresta.

Scenari comuni che coinvolgono Domain Naming Master

Potrebbe essere necessario modificare la foresta AD man mano che la tua azienda si evolve, oppure potrebbero essere aggiunti domini aggiuntivi alla tua foresta a causa di una fusione o acquisizione. Poiché l'aggiunta e la rimozione di domini e partizioni sono operazioni poco frequenti e raramente critiche in termini di tempo, il ruolo di Domain Naming Master comporta poco sovraccarico e la sua perdita può essere prevista con un impatto operativo nullo o minimo.

RID Master

Cos'è il ruolo del RID Master?

Il Relative Identifier Master (RID Master) è un ruolo a livello di dominio; esiste un RID Master in ogni dominio di una foresta AD. È responsabile dell'assegnazione dei pool di RID ai DC nel proprio dominio per garantire che ogni principale di sicurezza (come un utente o un gruppo) abbia un identificatore di sicurezza univoco.

Un (SID) è una stringa alfanumerica di lunghezza variabile che si presenta così:

      `S-1-5-21-1234567890-1234567890-1234567890-1001`
      

La prima parte della stringa è il SID del dominio, che è uguale per tutti i SID in un dominio. L'ultima parte è il RID, che è unico per ogni SID nel dominio. Nell'esempio sopra, 1001 è il RID assegnato a un particolare principale di sicurezza nel dominio.

Funzionalità e utilizzo del RID Master

Il RID Master assegna pool di RID ai DC. Ogni pool è composto da una gamma unica e contigua di RID, che il DC può utilizzare per generare un SID unico quando crea un principale di sicurezza. Gestendo centralmente la distribuzione dei RID, il RID Master garantisce che nessun controller di dominio assegni lo stesso RID a principali di sicurezza diversi, garantendo l'unicità di ogni SID all'interno del dominio.

Una volta che a un DC viene assegnato un pool di RID dal RID Master, non è necessario che comunichi con il RID Master ogni volta che crea un oggetto AD. Tuttavia, la perdita del RID Master di un dominio porterà infine all'impossibilità di creare nuovi oggetti nel dominio poiché i pool sui DC si esauriranno. In ambienti AD maturi, ciò richiederebbe un tempo considerevole poiché vengono creati relativamente pochi oggetti.

Generalmente, il ruolo di RID Master viene assegnato al controller di dominio primario (PDC) in un dominio perché il PDC di solito riceve la maggior parte dell'attenzione da parte degli amministratori e, di conseguenza, ha un'alta disponibilità. Nei domini maturi, il sovraccarico generato dal ruolo di RID Master è trascurabile. Sebbene questo ruolo non sia critico quanto alcuni degli altri ruoli, è comunque importante garantire la connettività al RID Master.

Emulatore PDC (PDCE)

Comprensione del ruolo di PDC Emulator: spiegazione e storia

Il Primary Domain Controller (PDC) è un termine dai tempi di Windows NT, quando un singolo DC aveva una copia scrivibile della directory. Oggi, la maggior parte dei DC in un dominio sono scrivibili, ma c'è ancora un DC designato che emula il ruolo di un PDC. Ogni dominio in una Foresta di Active Directory contiene un DC con il ruolo di PDCE.

Le funzioni di PDC Emulator in AD

L'Emulatore del Primary Domain Controller è responsabile delle seguenti operazioni:

• Sincronizzazione dell'orario — Il PDCE è la fonte autorevole dell'orario per il dominio; tutte le postazioni di lavoro e i server membri sincronizzano il loro orario con l'emulatore PDC. In una foresta multi-dominio, il PDCE nel dominio radice della foresta è il custode dell'orario per tutti gli altri emulatori PDC nella foresta. Per mantenere una sincronizzazione dell'orario accurata in tutta la foresta, l'emulatore PDC nel dominio radice dovrebbe essere configurato per sincronizzarsi con una fonte esterna affidabile dell'orario. L'orario è molto importante. Ad esempio, l'autenticazione Kerberos fallirà se la differenza tra l'orologio di un host richiedente e l'orologio del DC autenticante supera il massimo specificato (5 minuti per impostazione predefinita); ciò aiuta a contrastare determinate attività malevole, come gli attacchi di replay.
• Cambiamenti della password e autenticazione—Quando la password di un utente viene cambiata, la modifica viene inizialmente effettuata sul DC che ha autenticato l'utente. Questo aggiornamento della password confermato viene immediatamente replicato al PDCE del dominio. Se un account tenta di autenticarsi su un DC che non ha ancora ricevuto un recente cambio di password tramite la replica programmata, la richiesta viene passata al PDCE del dominio, che elaborerà la richiesta di autenticazione e istruirà il DC richiedente ad accettarla o rifiutarla. Questo comportamento assicura che le password possano essere elaborate in modo affidabile anche se i cambiamenti recenti non si sono ancora completamente propagati attraverso la replica programmata.
• Stato del blocco account — Allo stesso modo, se un account viene bloccato a causa di numerosi tentativi di accesso falliti, il blocco viene elaborato immediatamente nell'emulatore PDC e lo stato di blocco viene replicato su tutti i DC nel dominio per garantire che un account bloccato non possa accedere su un altro DC. Quando un amministratore sblocca un account, questa modifica viene replicata immediatamente in tutto il dominio.
• Aggiornamenti dei criteri di gruppo — Se vengono apportati aggiornamenti a un Group Policy object (GPO), vengono inizialmente eseguiti sul DC con il ruolo di Emulatore PDC. Questo previene conflitti di versione che potrebbero verificarsi se un GPO venisse modificato su due DC all'incirca nello stesso momento.
• Compatibilità con le versioni precedenti — Nelle organizzazioni che hanno ancora dispositivi o software legacy dipendenti da Windows NT, l'emulatore PDCE può fungere da PDC. Questo include il funzionamento come Master Browser, che raccoglie e distribuisce informazioni su applicazioni e dispositivi su una rete.
• Sistema di file distribuito (DSF) - Per impostazione predefinita, i server radice DFS richiederanno periodicamente informazioni aggiornate sul namespace DFS dal PDCE. Questo comportamento può portare a colli di bottiglia delle risorse, ma abilitando il Dfsutil.exe RootScalability parameter consentirà ai server radice DFS di richiedere aggiornamenti dal DC più vicino.

Il ruolo di PDC Emulator dovrebbe essere posizionato su un DC altamente accessibile, ben collegato e ad alte prestazioni, poiché la perdita del DC con questo ruolo può avere un impatto immediato e significativo sulle operazioni.

Infrastructure Master

Ruolo del Infrastructure Master FSMO

Il ruolo di Infrastructure Master è un ruolo a livello di dominio la cui funzione principale è gestire i riferimenti degli oggetti tra domini in una foresta multi-dominio. L'Infrastructure Master confronta gli oggetti nel suo dominio con gli oggetti in altri domini nella stessa foresta e li sincronizza con i server del global catalog.

Quando e perché è necessario Infrastructure Master

Queste azioni non sono necessarie in certi casi. Ovviamente, in ambienti con un solo AD domain, non ci sono riferimenti incrociati tra domini da gestire. E se tutti i DC in un dominio sono host di global catalog (cosa comune oggi a causa della migliore larghezza di banda della rete), avranno tutti informazioni aggiornate senza fare affidamento sull'Infrastructure Master.

Il Master dell'infrastruttura è incaricato delle seguenti responsabilità:

• Riferimenti incrociati di oggetti tra domini — In una foresta multi-dominio, oggetti di un dominio possono essere riferiti in un altro dominio. Un esempio tipico è quando un utente di un dominio viene aggiunto a un gruppo di sicurezza in un altro dominio. In questo scenario, viene creato un segnaposto (chiamato "oggetto fantasma") nel dominio del gruppo per rappresentare l'utente dell'altro dominio. Gli oggetti fantasma tracciano e gestiscono riferimenti persistenti a oggetti eliminati e attributi con valori di collegamento che si riferiscono a oggetti in un altro dominio nella foresta.
• Aggiornamento dei riferimenti gruppo-utente —L'Infrastructure Master è responsabile dell'aggiornamento dell'SID e del nome distinto (DN) di un oggetto in un riferimento a oggetti cross-domain e della traduzione di GUID, SID e DN tra domini in una foresta.
• Pulizia degli oggetti obsoleti — Il Master dell'infrastruttura controlla regolarmente il suo dominio per oggetti che non sono più validi (come oggetti da trust eliminati) e li rimuove.

Se un DC con il ruolo di Infrastructure Master fallisce, l'impatto è principalmente amministrativo. Anche se i nomi dei collegamenti degli oggetti tra domini potrebbero non risolversi correttamente durante la sua assenza, le appartenenze ai gruppi tra domini continueranno a funzionare.

Ruoli FSMO in contesti di Foresta e Dominio

Ruoli FSMO a livello di foresta

Come puoi vedere dall'elenco sopra, gli ultimi due ruoli FSMO operano a livello di foresta, il che significa che solo un DC nella foresta può essere il detentore del ruolo. In altre parole, ogni Foresta di Active Directory ha un unico Schema Master e un unico Domain Naming Master.

Ruoli FSMO a livello di dominio

Gli altri tre ruoli FSMO operano all'interno della giurisdizione di un singolo dominio. In ogni dominio, c'è un Infrastructure Master, un RID Master e un Emulatore PDC. Ogni dominio ospiterà questi tre ruoli FSMO in ambienti con più domini su uno o più DC.

Gestione dei ruoli FSMO

Identificazione dei detentori dei ruoli FSMO

Sapere quali DC nel tuo ambiente AD ospitano i 5 ruoli FSMO è importante. Ci sono diversi modi per identificare i DC che possiedono i ruoli FSMO. Un modo rapido è utilizzare il prompt dei comandi usando il seguente comando:

      netdom query fsmo /domain:<DomainName>
      

Ecco un esempio:

Puoi anche utilizzare PowerShell usando lo script seguente:

      (Get-ADForest).Domains |

ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `

Select-Object Domain, HostName, OperationMasterRoles
      

Ecco un esempio qui sotto che utilizza PowerShell:

Puoi anche scoprire quali DC sono assegnati i ruoli FSMO utilizzando gli strumenti di Windows Active Directory Tools. Utilizzando Active Directory Users and Computers, fai clic destro sul tuo dominio e seleziona Operations Masters come mostrato di seguito:

Quindi fai clic su ogni scheda per trovare i tre FSMO di dominio.

You can use Active Directory Domains and Trusts to find which DC holds the Domain Naming Master role by right-clicking on Active Directory Domains and Trust and then selecting Operations Master, as shown below.

Ciò aprirà il seguente pop-up per identificare l'attuale detentore del ruolo.

Il processo di identificazione dello Schema Master FSMO è un po' più complesso. Puoi scoprire la sua identità utilizzando lo snap-in dello Schema di Active Directory, tuttavia, lo snap-in non appare per impostazione predefinita all'interno di Windows Server. Per accedervi è necessario registrarlo utilizzando il file Schmmgmt.dll. Per farlo, clicca su Start > Esegui, e digita regsvr32 schmmgmt.dll nella casella Apri. Poi clicca OK come mostrato di seguito.

Una volta registrato con successo, è necessario eseguire le seguenti operazioni:

1. Nel menu Console, fare clic su Add/Remove Snap-in, fare clic su Aggiungi, fare doppio clic su Schema di Active Directory, fare clic su Chiudi e poi su OK.
2. Fare clic con il pulsante destro del mouse su Active Directory Schema nel riquadro in alto a sinistra e quindi fare clic su Operations Masters per visualizzare il server che detiene il ruolo di schema master.

Un esempio è mostrato nello screenshot qui sotto:

Questo ti darà accesso allo snap-in da cui puoi fare clic con il tasto destro su Active Directory Schema e scegliere Operations Master.

Trasferimento e acquisizione dei ruoli FSMO

Quando e come trasferire i ruoli FSMO

Mentre Active Directory assegnerà automaticamente i ruoli FSMO ai tuoi DC, ci sono momenti in cui potresti voler trasferire un ruolo a un altro DC. Ad esempio, potrebbe essere necessario mettere offline un DC per manutenzione che attualmente detiene un ruolo assegnato. Sia gli amministratori di dominio che quelli aziendali hanno la discrezione di spostare questi ruoli tra i controller di dominio secondo necessità.

Assunzione dei ruoli FSMO

Per il trasferimento dei ruoli FSMO, sia il detentore attuale sia il controller di dominio di destinazione devono essere attivi e connessi alla rete. Se il detentore attuale del ruolo FSMO non è disponibile e non può essere ripristinato, un amministratore di dominio o aziendale dovrà impadronirsi del ruolo. Poiché questa è una mossa più brusca, l'assunzione di un ruolo FSMO dovrebbe essere condotta solo quando necessario.

Migliori pratiche e risoluzione dei problemi

Ottimizzazione del posizionamento dei ruoli FSMO per una maggiore efficienza

Anche se non esistono regole ferree e veloci riguardo al posizionamento degli FSMO all'interno di Active Directory, le seguenti raccomandazioni ti garantiranno i migliori risultati:

• Posizionare l'Emulatore PDC e il Master RID su un domain controller affidabile con una buona connettività, che sia facilmente accessibile agli altri domain controller, poiché i loro ruoli sono fondamentali per le attività quotidiane di Active Directory.
• Se possibile, l'Infrastructure Master non dovrebbe essere posizionato su un server di catalogo globale. Questo non è possibile, naturalmente, se tutti i DC sono server di catalogo globale.
• Posiziona i due ruoli lato foresta (Schema Master e Domain Naming Master) sullo stesso DC, poiché non vengono utilizzati molto spesso.

Problemi comuni e soluzioni

Ci sono alcuni casi chiave che potrebbero indicare che un FSMO non è disponibile. Ad esempio, qualsiasi tentativo di aggiornare lo schema AD si tradurrà in un errore se lo Schema Master non è attivo. Sarà inoltre impossibile aggiungere o rimuovere domini nella foresta se il Domain Naming Master non è accessibile. In queste circostanze, è necessario confermare quale DC ha quel ruolo e verificare che sia accessibile.

L'impossibilità di accedere a un DC con un ruolo FSMO assegnato può derivare da molteplici fattori, tra cui:

• Il server è offline o spento
• Problemi di connettività di rete
• Errori o malfunzionamenti nella configurazione DNS

La risoluzione di questi problemi può richiedere l'utilizzo di strumenti diagnostici di rete per verificare la connettività in tutta la rete, verificare le impostazioni DNS compresi i record SRV e assicurarsi dello stato di salute fisico e logico del server che detiene il ruolo FSMO. Se il problema persiste, prendere in considerazione il trasferimento del ruolo a un altro DC sano o, come ultima risorsa, l'usurpazione del ruolo se l'attuale detentore è permanentemente non disponibile.

Monitoraggio e auditing dei ruoli FSMO

Poiché questi ruoli FSMO sono così critici, dovresti monitorare regolarmente i server che detengono questi ruoli. A un livello molto basilare, puoi controllare i log degli eventi sui tuoi controller di dominio. Eventi specifici possono indicare quando i ruoli FSMO sono stati trasferiti o sequestrati. La tua organizzazione potrebbe anche utilizzare software di monitoraggio o gestione che potrebbe avere dati storici o avvisi relativi ai cambiamenti dei ruoli FSMO. Ci sono anche strumenti di terze parti che offrono molte più funzionalità. Un esempio è Netwrix Auditor for Active Directory che automatizza il monitoraggio dei ruoli FSMO e può avvisarti di qualsiasi cambiamento sospetto o imprevisto. È anche considerata una best practice documentare quando avvengono questi cambiamenti dei ruoli FMSO in modo che questo tipo di cronologia possa essere accessibile se necessario.

Come Netwrix può aiutare

Come abbiamo visto, i ruoli FSMO sono importanti sia per la continuità operativa che per la sicurezza. Pertanto, è fondamentale eseguire l'audit di tutte le modifiche ai tuoi ruoli FSMO. Netwrix Auditor for Active Directory automatizza questo monitoraggio e può avvisarti di qualsiasi cambiamento sospetto in modo che tu possa agire prima che porti a inattività o a una violazione dei dati.

Ovviamente, proteggere i ruoli FSMO è solo una parte di una strategia di sicurezza. Netwrix Auditor for Active Directory offre una visibilità completa e il controllo sui sistemi fondamentali di cui hai bisogno. Monitora e analizza continuamente le modifiche e altre attività in Active Directory per individuare minacce emergenti e ti dà la possibilità di rispondere prontamente ed efficacemente per minimizzare l'impatto sui processi aziendali, la produttività degli utenti e la sicurezza.

Conclusione

I ruoli FSMO in AD sono un esempio di quanto accade sotto la superficie. Sebbene i ruoli FSMO a livello di foresta possano non essere critici ogni giorno, la tua attività dipende dai ruoli FSMO del dominio e dai servizi. Oltre alla minaccia di guasti previsti che si verificano periodicamente, questi ruoli sono obiettivi ideali per attori minacciosi malintenzionati che mirano a interrompere le operazioni aziendali. Questo significa che hai bisogno di visibilità nelle complessità del tuo ambiente AD.

I team di supporto AD adottano sempre più strumenti di monitoraggio automatizzati per affrontare queste sfide. Queste soluzioni possono fornire:

• Maggiore visibilità sullo stato e le prestazioni dei detentori di ruoli FSMO
• Allerte in tempo reale riguardo a qualsiasi cambiamento o anomalia negli assegnamenti dei ruoli FSMO
• Identificazione proattiva di potenziali problemi prima che possano aggravarsi
• Capacità di auditing estese che possono tracciare le modifiche storiche.

Questo approccio proattivo può aiutare gli amministratori AD a mantenere la salute e la stabilità di un'infrastruttura AD e a rafforzare la postura di sicurezza complessiva dell'organizzazione.

FAQ

Cos'è FSMO?

FSMO sta per Flexible Single Master Operations. Queste operazioni sono responsabilità speciali assegnate a specifici controller di dominio per prevenire conflitti e garantire il funzionamento fluido della rete.

Cosa sono FSMO e i suoi ruoli?

Active Directory si basa su un modello multi-master in cui FSMO assegna autorità designate a controller di dominio designati.

Quali sono i 5 ruoli FSMO e come si controllano i detentori dei ruoli?

I 5 ruoli FSMO sono i seguenti:

• Schema Master: Responsabile degli aggiornamenti allo schema di AD.
• Domain Naming Master: Controlla l'aggiunta o la rimozione di domini nella foresta.
• Master RID (Relative ID): Assegna pool di RID ai DC per creare identificatori di sicurezza unici (SIDs).
• Emulatore PDC (Primary Domain Controller): Questo gestisce i cambiamenti di password e la sincronizzazione dell'orario e funge da riserva per certi tipi di autenticazione.
• Infrastructure Master: Gestisce i riferimenti a oggetti in altri domini

Utilizzando gli strumenti standard di Active Directory e PowerShell, puoi scoprire quali controller di dominio detengono questi ruoli FSMO.

Dove si trovano i ruoli FSMO?

Per impostazione predefinita, il primo controller di dominio di un dominio radice della Foresta di Active Directory ospita lo Schema Master e il Domain Naming Master. Il primo controller di dominio di ogni dominio ospita l'Emulatore PDC, il RID Master e l'Infrastructure Master. Gli amministratori di Active Directory possono spostare questi ruoli su altri DC se lo desiderano.

Perché dobbiamo sequestrare i ruoli FSMO?

Se un domain controller si disconnette improvvisamente, il suo ruolo FSMO diventa indisponibile. Non è possibile trasferire il ruolo se non c'è connettività con il detentore originale del ruolo. In quel caso, il ruolo dovrà essere sequestrato e assegnato a un altro DC.

Qual è il ruolo FSMO più importante?

Mentre tutti i ruoli FSMO sono importanti, l'Emulatore PDC è il più cruciale poiché gestisce l'orario per il dominio, i cambiamenti delle password e la configurazione delle group policy. In alcuni casi, i sistemi legacy possono dipendere da esso come unico mezzo per gestire le richieste di autenticazione.

Come trovo i ruoli FSMO?

Ci sono diversi modi per scoprire quali controller di dominio hanno i ruoli FSMO di Active Directory. Uno è utilizzare il comando “netdom query fsmo” tramite il prompt dei comandi. È possibile anche utilizzare gli strumenti di Active Directory e PowerShell per scoprire quale server ospita ogni ruolo.

Dove dovrebbero essere collocati i ruoli FSMO?

Se hai solo uno o due controller di dominio nel tuo ambiente AD, non hai molta scelta in merito. Tutti i ruoli FSMO dovrebbero essere assegnati a un DC che abbia una buona connettività con tutti gli altri DC nella foresta. Se possibile, l'Infrastructure Master non dovrebbe essere posizionato su un server di catalogo globale.

Quali ruoli FSMO dovrebbero essere insieme?

I due ruoli FSMO a livello di foresta dello Schema Master e del Domain Naming Master dovrebbero essere posizionati sullo stesso DC, ma è solo una raccomandazione.

Cosa sono i ruoli FSMO in Active Directory?

Microsoft ha ridotto il rischio di conflitti designando specifici controller di dominio come unica autorità per cinque operazioni sensibili. Queste sono le funzioni Flexible Single Master Operations (FSMO), e comprenderle è fondamentale per gestire un ambiente Active Directory stabile e ben governato.

Active Directory funziona con un modello multi-master in cui ogni controller di dominio mantiene una copia scrivibile della propria partizione di dominio. Questo design garantisce resilienza (le operazioni continuano anche quando singoli DC sono offline), ma introduce anche la possibilità di modifiche conflittuali.

Questa guida spiega ciascuno dei cinque ruoli FSMO, come identificare quali controller di dominio li detengono e fornisce i comandi necessari per trasferire o acquisire i ruoli quando le circostanze lo richiedono.

Ognuno dei cinque ruoli FSMO appartiene a uno di due ambiti:

Per impostazione predefinita, quando promuovi il primo controller di dominio in una foresta, tutti e cinque i ruoli FSMO vengono assegnati a quel controller. Gli amministratori possono ridistribuirli man mano che l’ambiente cresce e le esigenze operative evolvono.

FSMO sta per Flexible Single Master Operations e si riferisce a cinque operazioni di Active Directory che solo un controller di dominio designato può elaborare alla volta. Limitando queste operazioni a un singolo DC autorevole per ambito, Active Directory previene collisioni di dati che si verificherebbero se più controller tentassero di eseguirle simultaneamente.

Netwrix Auditor monitora le assegnazioni dei ruoli FSMO in Active Directory e avvisa il tuo team quando un trasferimento o un’acquisizione di ruolo avviene fuori da una finestra di manutenzione pianificata. Richiedi una demo

Perché la replica multi-master richiede operazioni single-master

I ruoli con ambito forestale hanno esattamente un titolare in tutto il forest AD, indipendentemente dal numero di domini contenuti nel forest. I ruoli con ambito di dominio hanno esattamente un titolare per dominio Active Directory, quindi un forest con tre domini contiene tre RID Masters, tre PDC Emulators e tre Infrastructure Masters.

Importanza dei ruoli FSMO

Prevenzione dei conflitti

I primi servizi di directory di rete si basavano su un modello a master singolo: un server deteneva la copia modificabile del database degli account mentre tutti gli altri mantenevano repliche di sola lettura. Quel modello evitava conflitti ma creava una forte dipendenza da un singolo server: se andava offline, non si potevano creare nuovi account né modificare quelli esistenti.

I ruoli FSMO mantengono Active Directory coerente, sicuro e recuperabile. La loro importanza diventa chiara solo quando qualcosa va storto: un controller di dominio fallisce, è necessaria una trasferimento del ruolo sotto pressione o un attaccante prende di mira un titolare del ruolo.

Active Directory ha sostituito quel modello con la replica multi-master. Ogni controller di dominio può scrivere sulla propria copia locale della directory e le modifiche si propagano a tutti gli altri controller tramite replica programmata. Il design garantisce resilienza, ma espone operazioni specifiche in cui due controller che agiscono simultaneamente potrebbero corrompere la directory. I ruoli FSMO risolvono questo imponendo un’autorità a master singolo proprio dove il modello multi-master non può operare in sicurezza.

Affidabilità dell'autenticazione

Postura di sicurezza

Senza autorità designate a maestro singolo, due controller di dominio potrebbero elaborare contemporaneamente operazioni in conflitto: uno assegna RID 1050 a un nuovo account utente mentre l’altro assegna lo stesso RID a un account diverso, oppure due amministratori estendono lo schema con definizioni di attributi incompatibili. Entrambi i risultati causano corruzione della directory senza una soluzione chiara. I ruoli FSMO garantiscono che ogni operazione sensibile abbia esattamente una fonte autorevole in ogni momento.

Ripristino di emergenza

Quali sono i 5 ruoli FSMO

La designazione FSMO del PDC Emulator è il motivo per cui il tuo help desk può sbloccare un account e far sì che l’effetto si propaghi in pochi secondi in tutto il dominio. Senza di essa, Kerberos authentication le decisioni si baserebbero sulla versione della password che un determinato DC possiede in quel momento, creando condizioni di gara tra cambiamenti recenti della password e tentativi di accesso. Il modello a master singolo per l’elaborazione delle password fornisce a ogni DC un percorso noto di escalation per i fallimenti di autenticazione, e questo percorso funziona solo perché un DC detiene il ruolo di PDC Emulator.

Tre dei cinque ruoli FSMO si trovano direttamente nel percorso di scenari di attacco ad alto valore. Lo Schema Master controlla se un attaccante può estendere lo schema della directory per introdurre meccanismi di persistenza. Il RID Master controlla l'assegnazione SID, e la manipolazione del RID è un vettore noto per privilege escalation e attacchi alla cronologia SID. Il PDC Emulator gestisce l'autenticazione e i blocchi degli account, rendendolo un obiettivo principale per chiunque cerchi di mantenere l'accesso al dominio o sopprimere gli avvisi di blocco.

Active Directory definisce cinque ruoli FSMO. Lo Schema Master e il Domain Naming Master operano a livello di foresta. Il RID Master, PDC Emulator e Infrastructure Master operano a livello di dominio.

1. Schema Master

Quando un controller di dominio con un ruolo FSMO fallisce, il percorso di recupero dipende dal fatto che il tuo team conosca i ruoli che deteneva e se il guasto sia temporaneo o permanente. Le organizzazioni che non tengono traccia delle assegnazioni di ruolo scoprono la lacuna sotto pressione: non è possibile creare nuovi account utente, la sincronizzazione dell'ora si discosta o gli aggiornamenti di Group Policy smettono di propagarsi. Documentare i titolari dei ruoli e testare le procedure di trasferimento sono la base operativa per la resilienza di AD.

Ogni foresta ha un Schema Master. Lo schema del Active Directory database definisce ogni classe di oggetto (utenti, gruppi, computer, stampanti e altro) e ogni attributo che quegli oggetti possono contenere. Solo lo Schema Master può scrivere modifiche allo schema.

2. Master di denominazione del dominio

Ogni forest ha un Domain Naming Master. È l'unico controller di dominio autorizzato ad aggiungere o rimuovere domini e partizioni di applicazioni dal forest.

Gli aggiornamenti dello schema sono poco frequenti. Avvengono quando si aumenta il livello funzionale della foresta, si aggiorna Active Directory a una versione più recente, si integra un software aziendale che estende lo schema (Exchange Server è un esempio comune) o si introduce una nuova versione del sistema operativo Windows Server nella foresta. Lo Schema Master deve essere online e raggiungibile affinché una di queste operazioni abbia successo.

Una volta confermata, una modifica dello schema si replica su ogni domain controller nella foresta. Se lo Schema Master è offline quando tenti un aggiornamento dello schema, l’operazione fallisce finché il DC non è nuovamente accessibile.

3. RID Master

Un SID segue questa struttura:

Interagisci con il Domain Naming Master quando la struttura della directory della tua organizzazione cambia: aggiungendo un dominio figlio, rimuovendo un dominio obsoleto o assorbendo domini da un’azienda acquisita. Poiché queste operazioni sono rare e raramente critiche in termini di tempo, il Domain Naming Master ha requisiti di disponibilità inferiori rispetto ai ruoli a livello di dominio. Una breve interruzione del Domain Naming Master non ha impatto sulle operazioni quotidiane.

Il RID Master mantiene questa unicità assegnando pool di RID ai controller di dominio. Quando un DC deve creare un nuovo principale di sicurezza, preleva un RID dal pool assegnato invece di contattare il RID Master per ogni oggetto. Quando un pool si esaurisce, il DC ne richiede uno nuovo al RID Master.

Se il RID Master va offline, i controller di dominio continuano a creare oggetti utilizzando i loro pool RID esistenti. In ambienti maturi con pool grandi, questo può continuare per un lungo periodo. Alla fine, una volta esauriti tutti i pool DC, la creazione degli oggetti fallisce.

4. Emulatore PDC

Ogni dominio ha un RID Master. Ogni principale di sicurezza in Active Directory (utenti, computer e gruppi) richiede un identificatore di sicurezza (SID) univoco. Un SID è composto da un prefisso a livello di dominio seguito da un identificatore relativo (RID). La parte RID è ciò che rende unico ogni SID all'interno del dominio.

Ogni dominio ha un emulatore PDC. Ha più responsabilità di qualsiasi altro ruolo FSMO e ha l'impatto più diretto sulle operazioni quotidiane del dominio. L'emulatore PDC gestisce quanto segue:

Il SID del dominio è lo stesso per tutti gli oggetti nel dominio. Il segmento finale (1001 in questo esempio) è il RID assegnato a un principal di sicurezza specifico.

• Sincronizzazione dell'ora: L'Emulatore PDC è la fonte autorevole dell'ora per il suo dominio. Tutte le workstation e i server membri sincronizzano i loro orologi con esso. In una foresta multi-dominio, l'Emulatore PDC nel dominio radice della foresta agisce come orologio per tutti gli altri Emulatori PDC nella foresta. L'Emulatore PDC nel dominio radice dovrebbe sincronizzarsi con una fonte di tempo esterna affidabile. L'autenticazione Kerberos fallisce quando la differenza di orario tra un client e il suo DC autenticante supera i cinque minuti; l'ora precisa non è opzionale.
• Elaborazione del blocco account: Quando si verifica un account lockout, l'emulatore PDC lo elabora immediatamente e replica lo stato di blocco a tutti i DC nel dominio. Quando un amministratore sblocca un account, l'emulatore PDC replica subito la modifica.
• Modifiche della password e autenticazione: Quando un utente cambia una password, la modifica viene replicata immediatamente al PDC Emulator. Se un utente tenta di autenticarsi su un DC che non ha ancora ricevuto la password aggiornata tramite la normale replicazione, quel DC inoltra la richiesta di autenticazione al PDC Emulator. Questo garantisce che il dominio accetti credenziali valide anche quando le modifiche recenti della password non si sono ancora propagate tramite la replicazione programmata.

Posiziona l'emulatore PDC su un DC ad alte prestazioni con buona connettività di rete verso tutti gli altri controller del dominio. Il suo guasto ha un impatto immediato e visibile sulle operazioni.

• Sincronizzazione dello spazio dei nomi DFS: Per impostazione predefinita, i server root DFS richiedono informazioni aggiornate sullo spazio dei nomi al PDC Emulator. In ambienti di grandi dimensioni, questo può creare colli di bottiglia nelle risorse. Abilitare il parametro RootScalability in Dfsutil.exe consente ai server root DFS di richiedere aggiornamenti al DC più vicino.

5. Master dell'Infrastruttura

• Aggiornamenti di Group Policy: Le modifiche a un Group Policy Object vengono inizialmente applicate al DC che detiene il ruolo di PDC Emulator. Questo previene conflitti di versione che si verificherebbero se due amministratori modificassero lo stesso GPO su DC diversi contemporaneamente.

Ogni dominio ha un Infrastructure Master. La sua responsabilità principale è mantenere riferimenti accurati agli oggetti tra domini in una foresta multi-dominio.

Se l'Infrastructure Master va offline, i nomi degli oggetti cross-domain potrebbero non risolversi correttamente. Le appartenenze ai gruppi cross-domain continuano a funzionare, quindi l'impatto operativo è principalmente amministrativo.

Come trovare i titolari dei ruoli FSMO

Due condizioni rendono superfluo l'Infrastructure Master: foreste a dominio singolo (non esistono riferimenti tra domini) e ambienti in cui ogni DC è anche un server di catalogo globale (comune negli ambienti moderni con larghezza di banda di rete sufficiente). In entrambi i casi, tutti i DC possiedono già informazioni aggiornate tra domini senza fare affidamento sull'Infrastructure Master.

Quando un utente di un dominio viene aggiunto a un gruppo di sicurezza in un altro dominio, Active Directory crea un oggetto segnaposto (chiamato oggetto fantasma) nel dominio del gruppo per rappresentare l’utente cross-domain. L’Infrastructure Master mantiene aggiornati questi oggetti fantasma sincronizzandoli con il catalogo globale. Pulisce anche gli oggetti obsoleti rimuovendo i riferimenti a oggetti da trusts o domini.

Utilizzo di netdom query fsmo

Utilizzo di PowerShell

Sostituisci <DomainName>Expand con il nome di dominio completo del dominio di destinazione. L'output elenca il nome host del DC che detiene ogni ruolo.

Il comando netdomExpand viene eseguito su qualsiasi macchina Windows unita al dominio con RSAT installato, o direttamente su un controller di dominio. Restituisce tutti e cinque i titolari di ruolo in una singola query:

Utilizzo degli strumenti amministrativi di Active Directory

PowerShell offre un controllo più dettagliato e funziona bene in ambienti con più domini. Lo script seguente interroga tutti i domini nella foresta e restituisce ogni DC con un ruolo FSMO assegnato:

Sapere quali controller di dominio detengono i cinque ruoli FSMO è un prerequisito sia per la manutenzione programmata che per la risposta agli incidenti. Sono disponibili tre metodi utilizzando gli strumenti integrati di Active Directory management tools.

Per trovare il RID Master, PDC Emulator e Infrastructure Master:

1. Apri Utenti e computer di Active Directory.

Per una query più semplice per dominio, usa Get-ADDomainExpand e Get-ADForestExpand direttamente:

Gli strumenti GUI in Active Directory Users and Computers mostrano i tre ruoli FSMO a livello di dominio.

1. Fare clic con il tasto destro sul nome del dominio nel riquadro a sinistra e selezionare Operations Masters.
2. Apri Active Directory Domains and Trusts.

Per trovare il Domain Naming Master:

1. La finestra mostra l'attuale Domain Naming Master.
2. Controlla le schede RID, PDC e Infrastructure, ognuna mostra il titolare attuale del ruolo.
3. Fare clic con il tasto destro su Active Directory Domains and Trusts nel pannello a sinistra e selezionare Operations Master.

Per trovare lo Schema Master: Il componente aggiuntivo Active Directory Schema non si carica di default. Registralo prima:

Come trasferire i ruoli FSMO

1. Apri la finestra Esegui (Win + R) e inserisci regsvr32 schmmgmt.dll. ExpandFai clic su OK.

3. Fare clic con il tasto destro su Active Directory Schema nel pannello a sinistra e selezionare Operations Master per visualizzare l'attuale Schema Master.

2. Aprire MMC (mmc.exeExpand), andare su File > Aggiungi/Rimuovi snap-in, e aggiungere Active Directory Schema.

Un trasferimento sposta un ruolo FSMO dal suo attuale detentore a un altro DC mentre entrambi i controller sono online e comunicano. Usa un trasferimento per operazioni pianificate: dismettere un DC, ridistribuire i ruoli per carico o ridondanza, o sostituire hardware obsoleto.

Trasferimento tramite PowerShell

Trasferisci un singolo ruolo:

Trasferisci tutti e cinque i ruoli contemporaneamente:

Entrambi i DC devono essere online, raggiungibili e replicare correttamente prima di avviare un trasferimento. Verifica lo stato della replica con repadmin /replsummaryExpand prima di procedere.

PowerShell è il metodo più efficiente per trasferire i ruoli, soprattutto quando si spostano più ruoli contemporaneamente. Il Move-ADDirectoryServerOperationMasterRoleExpand cmdlet gestisce tutti e cinque i ruoli.

Trasferimento tramite GUI:

I cinque valori dei nomi dei ruoli sono SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster e InfrastructureMasterExpand.

Come acquisire i ruoli FSMO

Sostituisci TargetDCName Expandcon il nome NetBIOS o FQDN del DC di destinazione. PowerShell richiede conferma prima di trasferire ogni ruolo. Aggiungi -Confirm:$falseExpand per sopprimere le richieste negli scenari scriptati.

Dopo ogni trasferimento, eseguire netdom query fsmoExpand per confermare le nuove assegnazioni di ruolo.

Acquisizione di ruoli con ntdsutil:

Prima di sequestrare, prova a ripristinare o recuperare il DC originale. Se il recupero non è fattibile, procedi con il sequestro e assicurati di non ricollegare mai il DC originale al dominio senza prima degradarlo.

Per RID Master, PDC Emulator e Infrastructure Master: apri ADUC, vai a Operations Masters, seleziona la scheda pertinente e clicca su Change. Per il Domain Naming Master: usa Active Directory Domains and Trusts > Operations Master > Change. Per lo Schema Master: usa lo snap-in Active Directory Schema > Operations Master > Change.

Dopo la connessione, acquisisci ogni ruolo singolarmente:

Una seizure assegna forzatamente un ruolo FSMO a un nuovo DC senza coordinamento con il titolare originale. Usa una seizure solo quando il titolare attuale del ruolo è permanentemente offline e irrecuperabile. Non effettuare una seizure se il titolare originale potrebbe tornare in rete; riportare online un ex titolare del ruolo dopo una seizure causa una condizione di split-brain che richiede una correzione manuale.

Apri un prompt dei comandi con privilegi elevati sul DC che riceverà i ruoli ed esegui ntdsutilExpand. Quindi segui questi passaggi:

Digita quit Expanddue volte per uscire da ntdsutil dopo aver completato tutte le acquisizioni.

Best practice per il posizionamento dei ruoli FSMO

Conferma le nuove assegnazioni con netdom query fsmoExpand prima di rimettere online qualsiasi servizio che dipenda da quei ruoli.

La collocazione dei ruoli influisce direttamente sulla stabilità e sui tempi di recupero di AD. Consulta la guida alle best practice di sicurezza di Active Directory per raccomandazioni più ampie di rafforzamento insieme a queste linee guida specifiche per ruolo:

• Distribuisci i ruoli tra le sedi fisiche quando possibile: In ambienti multisito, posizionare i ruoli sui DC nel sito principale riduce la dipendenza dalla WAN per le operazioni dipendenti dai ruoli. Abbina questo a un piano di trasferimento documentato in modo che i ruoli possano spostarsi rapidamente se il sito principale va offline.
• Schema Master e Domain Naming Master insieme, su un DC meno utilizzato: Questi ruoli a livello di foresta sono raramente invocati. Raggrupparli sullo stesso DC semplifica l'amministrazione senza creare colli di bottiglia nelle prestazioni.

Per indicazioni su come configurare e impostare i controller di dominio per supportare queste decisioni di posizionamento, consulta la guida al deployment dei controller di dominio di Netwrix.

Come Netwrix Auditor ti aiuta a monitorare e controllare le modifiche del ruolo FSMO

• Emulatore PDC e RID Master sul DC più affidabile del dominio: Entrambi i ruoli richiedono alta disponibilità. Il guasto dell'Emulatore PDC ha un impatto immediato sugli utenti; il guasto del RID Master si accumula nel tempo man mano che le pool si esauriscono. Posizionali sul DC più affidabile e meglio connesso del dominio.
• Infrastructure Master fuori da un server catalogo globale: In ambienti in cui non tutti i DC sono anche server catalogo globale, l’Infrastructure Master dovrebbe funzionare su un DC che non possiede una copia del catalogo globale. Un Infrastructure Master che possiede anche un catalogo globale non trova mai oggetti fantasma da aggiornare, quindi non può mantenere aggiornati i riferimenti tra domini. Se tutti i DC nel tuo dominio sono server catalogo globale (comune negli ambienti moderni), questa restrizione non si applica.

Avvisi in tempo reale sui cambiamenti dei ruoli FSMO

Netwrix Auditor per Active Directory colma il divario tra ciò che i log nativi catturano e ciò di cui il tuo team di sicurezza ha bisogno per agire.

Active Directory registra i trasferimenti FSMO nel registro eventi del Directory Service sotto l'ID evento 1458, registrato sul controller di dominio che ha ricevuto il ruolo e nominando il precedente titolare. L'evento conferma che è avvenuto un trasferimento, ma non fornisce il contesto completo dell'account o i dettagli della sessione necessari per un'indagine.

Per avere un quadro completo di cosa monitorare nella tua directory, le Active Directory auditing guidelines coprono l'intera gamma di eventi da tenere sotto controllo.

Un trasferimento o sequestro non autorizzato del ruolo FSMO è un vettore di attacco confermato in AD con conseguenze oltre la semplice interruzione operativa. Un attaccante che ottiene privilegi sufficienti su un controller di dominio può sequestrare il ruolo di PDC Emulator per intercettare richieste di autenticazione, manipolare la sincronizzazione dell’ora o controllare la distribuzione di Group Policy nell’intero dominio. Questi cambiamenti potrebbero non apparire nei log eventi nativi di Windows con abbastanza contesto per identificare l’attore e l’intento.

Traccia completa di audit prima e dopo

Netwrix Auditor avvisa nel momento in cui un ruolo FSMO viene trasferito o acquisito. Gli avvisi si attivano indipendentemente dal fatto che la modifica sia stata effettuata tramite PowerShell, l'interfaccia grafica o ntdsutil, e includono l'account che ha avviato la modifica, la workstation di origine e il timestamp. Il tuo team può verificare immediatamente i trasferimenti pianificati e segnalare modifiche non riconosciute prima che si verifichino ulteriori danni.

Reportistica conforme alle normative

Distinguere i trasferimenti pianificati dalle acquisizioni non autorizzate

Ogni modifica del ruolo FSMO viene registrata con il titolare precedente, il nuovo titolare, l’account che ha eseguito l’azione e l’ora esatta della modifica. I log eventi nativi di Windows omettono questo contesto. Quando un incidente richiede una ricostruzione (per un’indagine interna o una verifica esterna), il record completo è disponibile senza fare affidamento sull’aggregazione dei log da più controller di dominio.

Poiché Netwrix Auditor cattura il contesto completo dell'account e della sessione, il tuo team può incrociare le modifiche dei ruoli con i record di gestione delle modifiche. Un trasferimento eseguito da un account amministratore nominato durante una finestra di manutenzione programmata appare diverso da un'acquisizione eseguita da un account senza attività amministrativa precedente. Il registro di controllo rende chiara e difendibile questa distinzione.

Richiedi una demo per vedere come Netwrix può aiutarti ad auditare i cambiamenti dei ruoli FSMO, tracciare ogni modifica di Active Directory e produrre le prove pronte per l'indagine di cui ha bisogno il tuo team di sicurezza.

Le assegnazioni dei ruoli FSMO fanno parte dell'impronta di accesso privilegiato che SOX, HIPAA, e le verifiche di ISO 27001 esaminano. Netwrix Auditor genera report predefiniti sui cambiamenti di privilegi in Active Directory che soddisfano le richieste degli auditor senza estrazione manuale dei log. La cronologia delle modifiche ai ruoli viene mantenuta e ricercabile, quindi le prove di conformità sono disponibili su richiesta anziché assemblate sotto pressione.