Valutare i metadati del descrittore di sicurezza dello schema AD

Cosa indicano i metadati del descrittore di sicurezza dello schema AD

I metadati del descrittore di sicurezza dello schema AD aiutano a valutare quando è stato modificato per l'ultima volta il descrittore di sicurezza della radice del contesto dei nomi dello schema. Un timestamp recente giustifica la raccolta di prove e la revisione della modifica. Non dimostra che un'autorizzazione sia diventata pericolosa, che un amministratore abbia agito senza autorizzazione o che la foresta sia stata compromessa.

Questa guida esamina nTSecurityDescriptor sull'oggetto esatto restituito come schemaNamingContext. Non esamina defaultSecurityDescriptor sulle singole classi dello schema. Conservate questa distinzione nel registro dell'indagine: una modifica al descrittore dell'oggetto radice e una modifica al descrittore predefinito di una classe sono oggetti di revisione diversi.

Microsoft descrive msDS-ReplAttributeMetaData come metadati mantenuti dal sistema per gli attributi replicati. Trattate queste informazioni come indicazione della provenienza della replica. Il server di directory di origine non è l'account umano o di servizio che ha richiesto una scrittura. Identificare l'account richiedente richiede prove separate.

Il risultato pratico è una scheda di valutazione: quale oggetto è stato interrogato, quale controller di dominio ha risposto, quali metadati sono stati restituiti, se il timestamp è utilizzabile e se un riferimento approvato spiega le autorizzazioni attuali. Questo è un processo di indagine, confrontato con la documentazione Microsoft il 4 ottobre 2026; nessuno dei comandi qui presentati è stato eseguito su una directory di un cliente.

Rilevamento: identificare l'oggetto prima di interrogare i metadati

Passaggio 1: risolvere il contesto dei nomi dello schema sul DC scelto

Usate una workstation amministrativa Windows con il modulo PowerShell ActiveDirectory e un account autorizzato a leggere i dati di directory pertinenti. Sostituite il server dell'esempio con un DC specifico della vostra foresta. Mantenete lo stesso server per l'individuazione e la prima interrogazione dei metadati.

L'esempio seguente usa il parametro documentato -Server di Get-ADRootDSE. L'output include schemaNamingContext, defaultNamingContext, il nome host del server e l'ora corrente.

$dc = 'dc01.example.com'
$root = Get-ADRootDSE -Server $dc -ErrorAction Stop
$root | Format-List dnsHostName, defaultNamingContext, schemaNamingContext, currentTime
$schemaDN = [string]$root.schemaNamingContext
if ([string]::IsNullOrWhiteSpace($schemaDN)) {
    throw 'Schema naming context was not returned; stop qualification.'
}

Registrate esattamente il DN restituito. Confrontatelo con il DN dell'oggetto usato dal vostro strumento di audit. Nel contesto di un dominio figlio, verificate in particolare se un DN costruito dal DN del dominio corrente corrisponde a RootDSE. Una discrepanza è un problema di raccolta da risolvere prima di interpretare il rilievo; non è una prova che il descrittore sia cambiato.

Passaggio 2: recuperare i metadati di replica dell'attributo

Get-ADReplicationAttributeMetadata accetta un nome distinto tramite -Object, un DC tramite -Server e nomi di attributi tramite -Properties. Questo esempio limita la richiesta a nTSecurityDescriptor e mostra tutti i metadati restituiti, senza nascondere campi in una tabella abbreviata.

$metadata = @(Get-ADReplicationAttributeMetadata -Object $schemaDN -Server $dc -Properties nTSecurityDescriptor -ErrorAction Stop)
if ($metadata.Count -eq 0) {
    throw 'No metadata was returned; record insufficient evidence.'
}
$metadata | Format-List *

Conservate l'output, inclusi il nome dell'attributo, la versione, l'ora dell'ultima modifica di origine e l'identità del server di directory di origine. Distinguete il DC interrogato dal server identificato come origine della modifica. Conservate ogni identità non risolta così come restituita; non sostituitela con un nome di amministratore presunto.

Passaggio 3: valutare il timestamp e la finestra di osservazione

Registrate l'ora e il fuso orario della raccolta insieme al timestamp originale. Confermate che la data sia presente e interpretata correttamente prima di applicare una finestra. Per riprodurre la decisione dell'audit, usate l'ora di riferimento registrata dall'audit, senza sostituirla silenziosamente con l'ora attuale durante un'indagine successiva.

Se ripetete la richiesta su un altro DC, ripetete anche lì l'individuazione RootDSE e salvate un registro di raccolta separato. Non fondete due osservazioni in una cronologia inventata. Il timestamp dell'ultima modifica non può ricostruire ogni stato precedente del descrittore o ogni modifica nel periodo esaminato.

Correzione: valutare prima, correggere la deriva confermata (Remediation)

Passaggio 1: confrontare il descrittore attuale con un riferimento approvato

Ottenete il descrittore attuale della radice esatta dello schema e confrontatelo con un riferimento datato e approvato per lo stesso oggetto. Per visualizzare le autorizzazioni sul DC selezionato, il comando seguente usa la sintassi per gli oggetti remoti documentata da Microsoft per Dsacls. Eseguite il comando da una shell Windows con privilegi elevati, con Dsacls installato e accesso in lettura all'oggetto di destinazione. Senza opzioni di modifica, mostra l'ACL.

dsacls "\\$dc\$schemaDN"

Conservate l'output del comando e segnalate ogni errore. La visualizzazione di un'ACL supporta la revisione delle autorizzazioni; conservate un'esportazione completa del descrittore tramite i vostri strumenti di directory approvati se l'indagine richiede anche informazioni su proprietario, gruppo o audit. Indicate esattamente quali componenti sono stati acquisiti, affinché una vista parziale non sia presentata come un confronto completo del descrittore.

Esaminate i destinatari modificati, i diritti, i GUID specifici degli oggetti, l'ereditarietà e l'ambito. Stabilite se ogni differenza riguarda la radice stessa o un altro oggetto. La revisione delle autorizzazioni dello schema fornisce un contesto correlato sulle autorizzazioni; questo controllo temporale non dimostra una modifica a defaultSecurityDescriptor di una classe.

Se non esiste un riferimento approvato, registrate questa limitazione. Il descrittore attuale può comunque essere esaminato rispetto alla delega prevista dall'organizzazione, ma resta indisponibile un confronto storico esatto. Non fabbricate uno stato precedente dal timestamp e non trattate un valore predefinito generico come il riferimento approvato della vostra foresta.

Passaggio 2: correlare l'autorizzazione e gli eventi disponibili

Confrontate le prove con un ticket di modifica reale: DN di destinazione, autorizzazioni attese, team responsabile, finestra di esecuzione approvata e stato risultante. Un ticket che cita una distribuzione relativa allo schema non è sufficiente da solo; verificate che la modifica prevista spieghi l'oggetto osservato e la differenza nel descrittore.

Microsoft documenta l'evento di sicurezza 5136 per le modifiche agli oggetti di directory nell'ambito di Audit Directory Service Changes. La generazione richiede una voce di audit appropriata per le scritture degli attributi nella SACL dell'oggetto. Dove esistono eventi, controllate ObjectDN e AttributeLDAPDisplayName, conservate i campi dell'account Subject e correlate le operazioni corrispondenti tramite OpCorrelationID. Microsoft descrive registrazioni tipiche Value Deleted e Value Added, ma verificate i valori realmente disponibili nelle vostre prove.

Usate la guida al monitoraggio AD per la raccolta e la correlazione degli eventi per esaminare la catena di monitoraggio circostante. Stabilite se audit, inoltro e conservazione coprivano il DC e il periodo pertinenti prima di interpretare una ricerca vuota. Un account Subject identifica il principal richiedente nell'evento; qualsiasi attribuzione a una persona specifica richiede comunque registri operativi di supporto.

Passaggio 3: scegliere una conclusione sostenibile

Un timestamp inspiegato, da solo, appartiene al terzo ramo. Una deviazione confermata delle autorizzazioni può giustificare una correzione senza stabilire chi l'abbia causata. Esplicitate la questione dell'autorizzazione e la valutazione dell'esposizione attuale, affinché la risposta non dipenda da un'attribuzione priva di supporto.

Passaggio 4: correggere solo la deviazione confermata del descrittore

Chiedete al team di directory autorizzato di preparare una modifica sul DN verificato della radice dello schema. Salvate il descrittore attuale, identificate l'ACE o il componente esatto da correggere, documentate il risultato previsto e predisponete un percorso di ripristino prima di scrivere. Applicate la modifica revisionata tramite il vostro editor ACL approvato, preservando la delega legittima e le autorizzazioni necessarie.

Evitate un ripristino generalizzato per liquidare un timestamp recente. La documentazione Dsacls di Microsoft descrive /S come ripristino dei valori predefiniti della classe e /R come rimozione di tutte le ACE per un principal specificato; nessuna delle due opzioni sostituisce una correzione mirata supportata dal vostro confronto approvato.

Dopo la correzione, ripetete le letture RootDSE, dei metadati e delle autorizzazioni. Verificate che lo stato previsto del descrittore sia presente e che le operazioni di directory necessarie continuino a funzionare. Registrate i nuovi metadati e le eventuali prove di audit raccolte come una nuova modifica autorizzata. Un rilievo di modifica recente può restare positivo dopo una correzione legittima, perché la correzione stessa è recente; convalidate le autorizzazioni, non soltanto la scomparsa del segnale temporale.

Come EtcSec rileva questo caso

Nell'implementazione esaminata di etc-collector, SCHEMA_SD_RECENT_CHANGE produce un rilievo Info con Count 1 quando SchemaSDLastChanged è diverso da zero e strettamente successivo a data.Now.AddDate(0, 0, -90). La soglia usa una sottrazione di giorni di calendario. Il limite esatto è escluso e non esiste un limite superiore a Now: anche una data futura supera il test. Altrimenti il rilievo restituito ha Count 0.

Il motore costruisce CN=Schema,CN=Configuration, seguito da DomainInfo.DomainDN, richiede i metadati di replica e copia l'ora della modifica per nTSecurityDescriptor. Confrontate questo DN costruito con l'effettivo schemaNamingContext di RootDSE, soprattutto quando il contesto di audit è un dominio figlio. Questa revisione del codice stabilisce un requisito di convalida, non un errore misurato nella vostra foresta.

Il provider LDAP cerca nel sottoalbero con risultati limitati a una voce e legge msDS-ReplAttributeMetaData. Risposte mancanti, errori di richiesta, tag XML assenti o timestamp non interpretati possono lasciare la data a zero. Il parser dei timestamp supporta YYYY-MM-DDTHH:MM:SSZ e YYYY-MM-DDTHH:MM:SS. Questo percorso non ha uno stato di verifica separato che dimostri il successo della raccolta.

Il rilevatore non confronta un vecchio descrittore con uno nuovo, non calcola differenze della DACL, non identifica un account richiedente e non dimostra un abuso. Usate il suo risultato Info per iniziare la valutazione. Count 1 supporta il predicato temporale implementato; Count 0 non può certificare uno schema invariato o una raccolta riuscita.