Siti e sottoreti AD: verificare la selezione del DC

Siti e sottoreti AD: cosa verificare prima di cambiare la topologia

Una verifica di siti e sottoreti AD deve rispondere a una domanda pratica: un client rappresentativo identifica il sito Active Directory previsto e individua un controller di dominio appropriato? Un sito senza oggetti server raccolti e un sito senza oggetti sottorete associati sono spunti utili per un’indagine. Nessuno dei due risultati, da solo, dimostra un attacco o stabilisce quale modifica di configurazione sia giustificata.

Questa guida è stata verificata rispetto a Microsoft Learn e all’implementazione di etc-collector il 3 ottobre 2026. I comandi seguenti sono esempi documentati di ispezione e configurazione; non sono stati eseguiti sul dominio di un cliente. Utilizzate l’inventario di rete, i risultati della directory e le osservazioni dei client per stabilire la causa prima di modificare un’associazione.

Una filiale può deliberatamente non avere un DC locale. Al contrario, un sito può avere un oggetto sottorete mentre altre reti reali dei client restano non dichiarate. Tenete distinti questi casi: il conteggio degli oggetti della directory non verifica la copertura di rete né il successo dell’autenticazione.

Come l’associazione al sito influisce sulla selezione del DC e sulla replica

La documentazione Microsoft su DC locator descrive l’individuazione tramite Netlogon, annunci DNS e risposte LDAP UDP. Durante la negoziazione, un DC identifica il sito del client dalla sua sottorete IP. Se il primo DC è esterno al sito appropriato, le informazioni restituite sul sito del client possono avviare un’altra ricerca specifica per quel sito. L’individuazione usa anche informazioni memorizzate nella cache; un singolo DC restituito è un’osservazione di quella richiesta, non una cronologia completa dell’autenticazione delle applicazioni.

Una sottorete client senza associazione lascia incompleta la selezione del sito e può portare a un DC esterno alla posizione prevista. È un motivo per esaminare l’indirizzo effettivo del client e la sua associazione, anziché supporre che ogni client scelga un DC a caso. Un DC remoto può anche essere il servizio previsto per una filiale che non ne abbia uno locale.

I concetti di replica di Microsoft distinguono gli oggetti sottorete, che associano gli indirizzi di rete ai siti, dai collegamenti tra siti e dagli oggetti connessione utilizzati per la replica. L’oggetto server di un DC ha un oggetto figlio NTDS Settings che rappresenta il DC che esegue la replica. Il KCC crea le connessioni di replica; i collegamenti tra siti descrivono percorsi logici e costi della replica.

Per questa verifica, mantenete separate due domande. L’individuazione da parte del client determina quale DC una macchina può trovare dalla rete attuale. La progettazione della replica determina come i DC si scambiano le modifiche della directory. Un’associazione corretta tra client e sito non dimostra il buon funzionamento della replica, e una replica riuscita non dimostra che ogni rete client abbia l’associazione al sito prevista.

La guida alla sicurezza delle zone DNS AD tratta trasferimenti, aggiornamenti dinamici e autorizzazioni dei record. Questi controlli sui dati di risoluzione completano l’indagine, ma non definiscono l’associazione tra sottorete e sito. Esaminate DNS quando l’individuazione fallisce, mantenendo distinte le evidenze sulla topologia.

Rilevamento: riconciliare l’inventario della directory con le osservazioni dei client

1. Stabilire cosa hanno effettivamente restituito le query alla directory

Utilizzate un host di gestione con il modulo PowerShell ActiveDirectory e un account autorizzato a leggere gli oggetti di configurazione pertinenti. I riferimenti Microsoft documentano Get-ADReplicationSubnet e Get-ADReplicationSite. I seguenti esempi in sola lettura richiedono gli oggetti e le loro proprietà:

Get-ADReplicationSubnet -Filter * -Properties *
Get-ADReplicationSite -Filter * -Properties *

Registrate il server di directory interrogato, il contesto dell’account, il successo della query e l’ora della raccolta insieme ai risultati. Esaminate i nomi delle sottoreti e le loro associazioni Site, quindi confrontate il sito associato con il nome distinto del sito. Non trasformate un errore di accesso o un’esportazione incompleta nella conclusione che gli oggetti non esistano.

Riconciliate l’esportazione con l’inventario attuale del team di rete: reti delle filiali, reti degli uffici, intervalli dei client VPN e altre reti da cui si connettono effettivamente i client del dominio. Per ogni intervallo pertinente, identificate il sito atteso e il responsabile che può confermarlo. Questo confronto è una fase di verifica manuale; i due controlli EtcSec descritti sotto non lo eseguono.

Iniziate con un piccolo insieme rappresentativo di client che includa le reti interessate dal rilievo. Registrate l’indirizzo attivo e il contesto della connessione per ogni osservazione. Un portatile verificato in ufficio e lo stesso portatile verificato tramite VPN sono osservazioni di rete diverse. Conservate il sito atteso e il motivo di quell’aspettativa prima di confrontare l’output dei comandi.

2. Osservare l’appartenenza al sito e il risultato di DC locator

La pagina Microsoft sulla risoluzione dei problemi di sincronizzazione della directory documenta questi comandi per verificare l’appartenenza del computer a un sito e individuare un DC. Sostituite il dominio di esempio con il vostro dominio DNS effettivo:

nltest /dsgetsite
nltest /dsgetdc:contoso.com

Leggete il sito risultante, il DC selezionato e i campi Our Site Name e DC Site Name quando vengono restituiti. Conservate gli errori come tali, incluso il relativo testo. Un risultato di sito non disponibile richiede un’indagine; non dimostra che il client appartenga all’ufficio geograficamente più vicino.

Per confrontare deliberatamente una nuova individuazione, il riferimento Nltest documenta /force come modo per evitare le informazioni di individuazione memorizzate nella cache:

nltest /dsgetdc:contoso.com /force

Conservate entrambi i risultati invece di sovrascrivere la prima osservazione. Confrontate il sito client indicato con l’associazione attesa e il sito del DC con la progettazione documentata della filiale. Se differiscono, esaminate l’associazione, l’individuazione e l’eccezione WAN prevista prima di modificare qualsiasi cosa. Questi comandi verificano l’individuazione; validate separatamente il comportamento dell’applicazione interessata se un problema di autenticazione ha motivato la verifica.

3. Correlare le evidenze dei client senza associazione

Microsoft documenta l’evento NETLOGON 5807 in Risposta ritardata del DC alle richieste LDAP o Kerberos. L’evento descrive connessioni da indirizzi di client che non corrispondono a siti esistenti. La pagina identifica %SystemRoot%\debug\netlogon.log e il relativo file ruotato .bak come posizioni dei nomi e degli indirizzi dei client, con NO_CLIENT_SITE: che identifica le voci pertinenti.

Quando sono presenti questo evento o le voci di log associate, riconciliate gli indirizzi osservati con l’inventario di rete e le sottoreti dichiarate. Verificate quale connessione abbia prodotto l’indirizzo prima di assegnarlo a un sito. L’assenza di questo evento non sostituisce il confronto con l’inventario, e la sua presenza non identifica un attaccante.

Correzione: sistemare l’associazione o documentare l’eccezione prevista (Remediation)

1. Risolvere prima l’incertezza sull’inventario

Prima di modificare la topologia, riconciliate l’istantanea del collector con letture riuscite della directory. Se l’enumerazione dei server o delle sottoreti è fallita, esaminate il contesto della raccolta e ripetete l’inventario. Non distribuite un DC, non eliminate un sito e non inventate una sottorete soltanto per cancellare un’assenza apparente prodotta da una query fallita.

Per un sito senza DC locale, chiedete ai responsabili del dominio e della rete se sia una scelta deliberata. Documentate la posizione del DC che fornisce il servizio, la dipendenza WAN prevista, il responsabile e la condizione che avvia una nuova verifica. Conservate questa eccezione insieme alle osservazioni dei client, affinché un altro revisore possa capire perché l’individuazione tra siti sia accettabile in quel caso.

2. Correggere un’associazione mancante o errata confermata

Identificate la rete reale dei client e il sito esistente che deve rappresentarla. Esaminate l’associazione proposta con il responsabile di rete, incluse le altre reti che potrebbero essere interessate. Una definizione di sottorete deve esprimere la progettazione di rete concordata, non limitarsi a copiare l’indirizzo della prima macchina che ha prodotto un errore.

Per una sottorete effettivamente mancante, Microsoft documenta questo esempio di creazione in New-ADReplicationSubnet:

New-ADReplicationSubnet -Name "10.10.0.0/22" -Site Asia -Location "Tokyo,Japan"

Si tratta della rete e del sito illustrativi di Microsoft, non di una configurazione proposta per il vostro ambiente. Sostituite una rete verificata e un sito esistente previsto solo dopo aver accertato che l’oggetto sottorete sia effettivamente mancante. Per un oggetto esistente con l’associazione errata, correggete la sua associazione Site in Active Directory Sites and Services tramite il normale processo di modifica. Conservate i valori originali e la sostituzione approvata nel registro della modifica.

Se un server è effettivamente dismesso, seguite le indicazioni separate sull’igiene degli oggetti DC e sulla pulizia dei metadati. Confermate la dismissione prima della pulizia. Un elenco vuoto di server raccolti non dimostra che si debba rimuovere un DC attivo, e aggiungere o rimuovere oggetti server non sostituisce la correzione dell’associazione delle sottoreti client.

3. Ricontrollare i client rappresentativi e conservare le evidenze

Ripetete l’inventario della directory e i comandi di individuazione dei client dopo che la modifica è visibile sul server di directory usato per la validazione. Verificate le stesse reti rappresentative, inclusi i casi previsti di servizio remoto. Registrate il sito atteso, il sito osservato, il DC restituito e l’eccezione residua per ogni client.

Ricontrollate il flusso dell’applicazione che ha motivato l’indagine e verificate separatamente la replica se la topologia è stata modificata. La scomparsa di un rilievo d’inventario conferma utilmente gli oggetti raccolti, ma non dimostra che ogni rete o applicazione utilizzi ora il percorso desiderato.

Come EtcSec rileva queste situazioni

L’implementazione di etc-collector di EtcSec valuta due controlli Network sull’inventario raccolto di siti e sottoreti:

• SITE_TOPOLOGY_ISSUES — Low. site-topology.go:23 scorre data.Sites e raccoglie ogni sito per cui len(site.Servers) == 0. Restituisce un rilievo il cui Count è il numero di tali siti, con i relativi nomi in sitesWithoutDc. Quando il conteggio è positivo, aggiunge le entità dei siti interessati. Restituisce il rilievo anche quando il conteggio è zero; in questo ramo non esiste alcuna condizione di latenza misurata.
• SUBNET_MISSING — Info. subnet-missing.go:24 cerca nelle sottoreti raccolte un Subnet.SiteDN corrispondente a ciascun Site.DistinguishedName usando strings.EqualFold. Un sito senza corrispondenze contribuisce a Count e a sitesWithoutSubnets; i dettagli includono anche i conteggi totali di siti e sottoreti. Le entità dei siti interessati vengono aggiunte solo quando IncludeDetails è abilitato e il conteggio è positivo. Una sola sottorete associata soddisfa questo predicato anche se altre reti reali restano senza associazione.

Il provider LDAP è rilevante per l’interpretazione. In client.go:1872, GetSitesAndSubnets cerca nel contenitore Servers di ogni sito con (objectClass=server). Sebbene il commento menzioni nTDSDSA, il codice non verifica un oggetto figlio NTDS Settings e non controlla lo stato del DC. Aggiunge il dNSHostName di un server, ripiegando su name, solo quando è disponibile un valore non vuoto.

Il fallimento di una query dei siti restituisce un errore. Il fallimento di una query dei server di un singolo sito viene ignorato e può lasciare Servers vuoto. Il fallimento di una query delle sottoreti restituisce sites, nil, nil, senza errore. Questi ultimi rami possono simulare un’assenza nei dati passati ai rilevatori. Un elenco di siti o sottoreti apparentemente vuoto richiede quindi evidenze d’inventario indipendenti e ottenute con successo.

Nessuno dei controlli analizza la copertura CIDR, valida gli indirizzi IP dei client, misura la latenza, valuta i costi dei collegamenti tra siti o le connessioni di replica, né verifica la raggiungibilità dei DC. Nessuno dimostra che ogni server dichiarato sia un DC funzionante. Un sito intenzionalmente privo di DC può produrre il rilievo Low, mentre un sito con una sottorete può evitare il conteggio Info nonostante lacune altrove.