Inventario dei controller di dominio AD: riconciliare i metadati FSMO

Cosa stabilisce un inventario dei controller di dominio AD

Un inventario dei controller di dominio AD deve identificare i DC inclusi nell’ambito e spiegare l’origine di ogni voce. Nomi, sistemi operativi, siti, indicatori di sola lettura, ruoli FSMO e partner di replica configurati aiutano l’operatore a comprendere la directory. Da soli, non dimostrano che un DC sia raggiungibile, che siano stati raccolti tutti i DC previsti o che le modifiche alla directory si stiano replicando correttamente.

La verifica pratica consiste nel riconciliare l’istantanea del collector con letture indipendenti della directory, conservando il dominio, il server interrogato, i contesti di denominazione e gli errori di raccolta. Un elenco FSMO vuoto deve restare distinguibile da una lettura riuscita che mostri che quel determinato DC non detiene alcun ruolo. Analogamente, un partner configurato fornisce informazioni sulla topologia, non un risultato di replica riuscito.

Questa guida è stata verificata rispetto a Microsoft Learn e al codice sorgente di etc-collector il 4 ottobre 2026. I comandi sono esempi documentati di ispezione in sola lettura o adattamenti di sintassi documentate. Non sono stati eseguiti sulla directory di un cliente. La procedura seguente propone una revisione delle evidenze, non descrive un incidente osservato.

Come l’ambito e i metadati facoltativi influenzano il risultato

Partire dal registro della raccolta anziché dalla sola visualizzazione. Identificare il dominio richiesto, l’endpoint LDAP, il BaseDN, il contesto dell’account, l’ora della raccolta e le esclusioni. Conservare i contesti di denominazione effettivamente coinvolti nelle letture, incluso il contesto di configurazione utilizzato per l’arricchimento. Un’etichetta di dominio senza il server e il contesto di ricerca non basta a spiegare perché due esportazioni differiscano.

Nel collector esaminato, i DC vengono derivati dagli oggetti computer raccolti dopo le esclusioni. Il provider di metadati arricchisce l’elenco fornito. Ciò significa che un partner che non può essere ricondotto all’elenco di DC fornito può essere omesso dal campo dei partner risultante. Un array vuoto può quindi descrivere una corrispondenza incompleta anziché l’assenza di oggetti di connessione.

Il provider costruisce inoltre la propria base di ricerca della configurazione anteponendo CN=Configuration, al BaseDN. Quando si esamina una raccolta relativa a un dominio figlio, confrontare quel contesto costruito con il contesto di configurazione effettivo della foresta utilizzato nell’ispezione indipendente della directory. La possibile discrepanza di ambito è un’inferenza statica dal codice, non un errore riprodotto nella foresta di un cliente. Conservare il contesto e il risultato della ricerca prima di decidere se spieghino un campo mancante.

Un registro di verifica utile associa ogni identificatore di DC alla sua origine e a uno stato di lettura esplicito. Gli stati suggeriti sono lettura riuscita, non raccolto, lettura non riuscita e non ancora verificato. Si tratta di etichette della procedura, non di valori emessi dal rilevatore. Non convertire silenziosamente nessuno degli ultimi tre stati in un elenco vuoto o in un indicatore falso.

Rilevamento: riconciliare DC e titolari FSMO in modo indipendente

1. Enumerare il dominio previsto

Utilizzare un host di gestione con il modulo PowerShell ActiveDirectory e un account autorizzato a leggere i dati pertinenti della directory. La documentazione di Get-ADDomainController di Microsoft descrive il set di parametri Filter e -Server. Il seguente adattamento richiede i DC a un server di directory nominato esplicitamente; sostituire il nome host illustrativo con il server verificato per il proprio dominio:

Get-ADDomainController -Filter * -Server "dc01.contoso.com"

Registrare il server effettivamente interrogato insieme agli oggetti restituiti e agli errori. Confrontare gli identificatori e l’appartenenza al dominio con le voci del collector prima di esaminare le differenze di arricchimento. Conservare gli oggetti mancanti da una delle due esportazioni come discrepanze da indagare, includendo eventuali esclusioni note che spieghino una differenza.

La documentazione distingue il recupero tramite Filter o Identity dall’individuazione. Una chiamata di individuazione trova un DC che soddisfa i suoi criteri; non enumera tutti i DC. Per una verifica dell’intera foresta, mantenere risultati separati per dominio. La documentazione di Get-ADForest include l’enumerazione attraverso la raccolta Domains della foresta. Non presentare un’esportazione riuscita di un singolo dominio come copertura completa della foresta.

2. Leggere i ruoli di ciascun DC, poi verificare i titolari di dominio e foresta

La pagina sulla gestione dei ruoli FSMO di Microsoft fornisce questo esatto esempio di ispezione del dominio corrente:

$domainControllers = Get-ADDomainController -Filter *
foreach ($dc in $domainControllers) {
    Write-Output "Name: $($dc.Name)"
    Write-Output "OperationMasterRoles:"
    foreach ($role in $dc.OperationMasterRoles) {
        Write-Output "- $role"
    }
}

Poiché questo esempio utilizza il contesto di connessione predefinito, registrarlo esplicitamente. Preferire l’enumerazione precedente con server esplicito quando si prepara un confronto controllato. Conservare gli oggetti DC completi restituiti e il riepilogo dei ruoli, affinché una scelta di formattazione non nasconda l’identità di origine.

La documentazione di Get-ADDomain espone PDCEmulator, RIDMaster e InfrastructureMaster. L’output di Get-ADForest espone SchemaMaster e DomainNamingMaster. Questi adattamenti in sola lettura utilizzano i rispettivi parametri Identity e Server documentati:

Get-ADDomain -Identity "contoso.com" -Server "dc01.contoso.com"
Get-ADForest -Identity "contoso.com" -Server "dc01.contoso.com"

Sostituire il dominio e la foresta previsti in modo indipendente; non devono necessariamente avere lo stesso nome DNS. Salvare l’output completo, inclusi l’identità del dominio restituita e l’appartenenza alla foresta. Confrontare ogni titolare con le proprietà dei ruoli di ciascun DC e con i metadati del collector. Un titolare di ruolo della foresta esterno a una raccolta di dominio figlio solleva una questione di ambito, non dimostra l’assenza di un ruolo.

3. Conservare i disaccordi e i dati non letti

Per ogni discrepanza, allegare entrambi gli output, le rispettive ore di raccolta, le identità dei server e gli esiti delle letture. Una lettura indipendente riuscita che identifichi un altro titolare può spiegare perché un DC non detenga alcun ruolo. Una lettura non riuscita non può farlo. Se le letture con server esplicito discordano, conservarle entrambe anziché scegliere quella che faccia apparire completo l’inventario.

Assegnare un responsabile all’indagine sul contesto di raccolta e su eventuali incoerenze della directory. La domanda immediata sulle evidenze è se il valore mancante rifletta l’ambito, un’esclusione, metadati non letti o uno stato verificato della directory. Rispondere a questa domanda prima di pianificare una modifica ad AD.

Correggere le evidenze prima di modificare la directory (Remediation)

1. Risolvere le lacune di raccolta e ripetere il confronto

Esaminare l’endpoint registrato, il BaseDN del dominio, il contesto di configurazione, le esclusioni e le autorizzazioni con il responsabile della directory. Correggere un problema confermato del contesto di raccolta tramite la procedura di configurazione supportata dal collector. Conservare insieme l’istantanea originale, il motivo della correzione e i nuovi risultati delle letture.

Ripetere l’enumerazione dei DC nell’ambito definito e i comandi di ispezione di dominio e foresta riportati sopra. Confrontare nuovamente gli stessi identificatori e le stesse proprietà dei ruoli. Se i metadati restano non letti, lasciare visibile quello stato e assegnare l’indagine irrisolta; compilare manualmente il campo del rapporto distruggerebbe la distinzione tra una lettura della directory e un’ipotesi dell’operatore.

Un registro di accettazione deve indicare quale dominio è stato riconciliato, quali DC restano senza spiegazione, quali titolari di ruolo sono stati letti indipendentemente e quali campi restano sconosciuti. Trattare un DC escluso come escluso, anziché segnalarlo come assente dalla directory. Ripetere con successo una raccolta è un’evidenza utile, ma non ne estende l’ambito oltre i domini e i contesti effettivamente interrogati.

2. Controllare la replica come verifica distinta

La guida alla risoluzione dei problemi di replica di Microsoft documenta questo esatto comando da un prompt dei comandi con privilegi elevati:

repadmin /showrepl * /csv > showrepl.csv

La procedura documentata richiede l’appartenenza a Enterprise Admins o autorizzazioni equivalenti. Seguire il processo diagnostico autorizzato dell’organizzazione. Conservare il CSV e gli errori del comando. Esaminare i partner di origine, i contesti di denominazione, le informazioni sull’ultima replica riuscita e gli errori separatamente dall’elenco dei partner configurati dell’inventario.

La stessa guida identifica il registro eventi Directory Service e l’output di Repadmin come evidenze per la risoluzione dei problemi. Utilizzare il testo effettivo dell’errore per indagare un risultato diagnostico non riuscito. Una connessione elencata in un inventario non risponde a queste domande sullo stato della replica, e una destinazione diagnostica non raggiungibile resta irrisolta anche se altri DC hanno restituito un output.

Registrare l’ambito e il risultato del controllo della replica in un registro di evidenze dedicato. Non sostituire il campo dei partner configurati con un giudizio sullo stato della replica né considerare sane tutte le connessioni perché una query è riuscita. Questo articolo sull’inventario non prescrive modifiche alla topologia o operazioni di ripristino a partire da una lacuna nei metadati.

3. Collegare l’inventario con i suoi limiti documentati alla pianificazione di topologia e ripristino

Utilizzare le informazioni sui siti verificate insieme alla selezione del DC da parte dei client e alla corrispondenza tra sottoreti e siti. Questa verifica riconcilia la topologia della directory con le reti client effettive e le osservazioni di individuazione. Il solo nome di un sito nell’inventario non dimostra né una selezione appropriata da parte dei client né il buon funzionamento della replica.

Fornire il registro riconciliato di DC e titolari dei ruoli come input per la pianificazione del ripristino della foresta e la validazione dei backup. La preparazione al ripristino richiede DC e ruoli noti, ma anche la selezione dei backup, evidenze di ripristino e una procedura operativa specifica dell’ambiente. Un’esportazione dell’inventario non convalida un ripristino né stabilisce che lo stato recuperato della directory sia affidabile.

Come EtcSec rileva questo aspetto

L’etc-collector di EtcSec emette INFO_DOMAIN_CONTROLLER come risultato di inventario. L’implementazione esaminata di dc-inventory.go produce un risultato Info con Count 1 per ogni DC raccolto. Non restituisce risultati quando l’elenco di DC fornito è vuoto. Questo comportamento non è un giudizio di vulnerabilità e non dimostra che una directory senza voci restituite non contenga DC.

Le entità interessate dettagliate vengono allegate solo con IncludeDetails. Contengono i campi di base dell’identità del computer e del sistema operativo, con ruoli FSMO, stato RODC, sito e partner di replica facoltativi. L’arricchimento mancante lascia array vuoti o valori predefiniti. Chi utilizza questi dati deve chiarire il significato di quei valori prima di trattarli come osservazioni negative ottenute da letture riuscite.

Il metodo GetDCMetadata del provider LDAP legge gli oggetti titolari dei ruoli e la configurazione NTDS/di connessione. Gli errori di ricerca FSMO o i risultati vuoti vengono saltati. Un errore di ricerca NTDS lascia non compilati i campi del sito e dei partner, mentre l’indicatore RODC e gli eventuali ruoli già letti restano disponibili; gli errori di ricerca delle connessioni vengono ignorati. Gli identificatori dei partner vengono ricondotti all’elenco di DC fornito. Il motore assegna inoltre DCInfo solo quando la chiamata dei metadati riesce.

Questi sono limiti osservati nel codice sorgente al commit afca1b9f7bba6f076d6a6493371486071001452b, non errori riprodotti presso clienti. Il controllo non verifica lo stato della replica, non misura alcuno scambio riuscito di modifiche e non prende decisioni sulla preparazione al ripristino. Utilizzarlo per rendere visibili gli asset DC raccolti, quindi chiarire la copertura e il significato dei metadati facoltativi con le letture indipendenti descritte sopra.