Comprensione dei 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.