Approvare modifiche AD: attributi e valori 5136 abbinati

Cosa significa approvare modifiche AD agli attributi?

Una revisione per approvare modifiche AD agli attributi collega una modifica registrata di un oggetto esistente della directory a una decisione autorizzata in modo indipendente. Il risultato è un registro delle prove: GUID dell'oggetto, attributo modificato, valori eliminati e aggiunti osservati, ID di correlazione dell'operazione, account richiedente, controller di dominio emittente, ora dell'evento e prove di approvazione. Il nome di un amministratore noto o un basso numero di segnalazioni sulla postura non può sostituire tale registro.

Utilizzare questa procedura quando una modifica della directory richiede una spiegazione prima di chiudere la revisione o approvare una modifica correttiva. Iniziare con un oggetto e un attributo. Conservare gli eventi originali, stabilire i limiti della raccolta e chiedere al decisore autorizzato di confermare se il cambiamento di valore osservato corrisponde alla richiesta. La revisione può concludersi con un'approvazione supportata da prove, una modifica non autorizzata confermata o una lacuna probatoria irrisolta; questi esiti richiedono azioni successive diverse.

Questo articolo riguarda le modifiche a un oggetto esistente. Per gli oggetti appena sottoposti a provisioning, utilizzare il registro di creazione che collega whenCreated e le prove di creazione al provisioning approvato. Per il confronto più ampio tra accesso previsto e diritti effettivi di gruppo, ACL e replica, utilizzare il flusso di revisione e riconvalida della deriva degli accessi privilegiati. Qui, il risultato da produrre è il registro delle prove di modifica dell'attributo, anziché un altro inventario di account privilegiati.

Come funziona: stabilire cosa può mostrare 5136

Microsoft documenta l'evento 5136 per le modifiche agli oggetti del servizio directory. Per generare l'evento, deve applicarsi l'audit dei successi di Directory Service Changes e l'oggetto deve disporre di una voce SACL corrispondente che controlli la scrittura dell'attributo pertinente. La sottocategoria di audit opera sui controller di dominio. Alcune modifiche di oggetti o proprietà non vengono sottoposte ad audit a causa delle impostazioni dello schema, quindi l'abilitazione dei soli criteri non stabilisce una copertura completa. Microsoft Learn: evento 5136, Audit Directory Service Changes.

Per una sostituzione, Microsoft descrive un tipico evento di valore eliminato seguito da un evento di valore aggiunto. Trattare questo schema come un aiuto alla ricostruzione. Non garantisce che ogni revisione disponga di esattamente due record. Un attributo può avere più valori, un'operazione può interessare più attributi e i record conservati possono essere incompleti. Mantenere ogni evento di valore pertinente e spiegare come contribuisce alla modifica esaminata.

Il campo XML OperationType distingue un'aggiunta, %%14674, da un'eliminazione, %%14675. AttributeValue contiene il valore coinvolto nell'evento. Conservare sia il codice grezzo dell'operazione sia il suo significato. Non interpretare un valore aggiunto come l'insieme completo dell'attributo dopo la modifica quando può rappresentare un solo elemento di un attributo multivalore. Microsoft Learn: descrizione dei campi dell'evento 5136.

OpCorrelationID collega le modifiche appartenenti a un'operazione LDAP. Può estendersi oltre il solo attributo in esame. Combinarlo con l'identità dell'oggetto e dell'attributo, la provenienza e l'ora; non è un riferimento a un ticket aziendale. Microsoft descrive AppCorrelationID come inutilizzato, con un trattino come valore. Nessuno dei due campi fornisce la decisione di approvazione dell'organizzazione.

Rilevamento: raccogliere un insieme di prove delimitato

I comandi seguenti utilizzano una sintassi documentata di comandi e parametri adattata a questa revisione. Non sono stati eseguiti su un dominio reale. Eseguire le letture degli eventi da un host Windows autorizzato; utilizzare il modulo Active Directory per leggere l'oggetto. Sostituire DC, intervallo UTC e GUID dell'oggetto di esempio con i dati effettivi del caso. Registrare gli errori di autorizzazione e i log non disponibili come osservazioni fallite, anziché come ricerche vuote riuscite. Le letture remote Get-WinEvent richiedono accesso attraverso il firewall al servizio Windows Event Log; il cmdlet non si basa su PowerShell remoting. Microsoft Learn: Get-WinEvent ComputerName.

Passo 1: registrare la copertura di audit e conservazione

Su ciascun DC pertinente al caso, esaminare la sottocategoria attuale di audit del sistema. Il nome inglese seguente richiede un'installazione che lo riconosca; la sintassi documentata accetta anche un GUID di sottocategoria.

auditpol /get /subcategory:"Directory Service Changes" /r

L'output atteso è un rapporto dei criteri che identifica la sottocategoria e le sue impostazioni di successo e fallimento. Salvare l'identità del DC, l'ora di raccolta, il comando e il rapporto restituito. Una query riuscita stabilisce cosa è stato letto in quel momento. Non dimostra che la stessa impostazione fosse applicata quando si è verificata la modifica storica. La sintassi del comando e i requisiti delle autorizzazioni di lettura sono documentati in Microsoft Learn: auditpol get.

Per la configurazione del log, esaminare il log Security sullo stesso DC:

Get-WinEvent -ListLog Security -ComputerName 'dc01.contoso.local' -ErrorAction Stop

Il risultato descrive il log, inclusi modalità, dimensione massima configurata e numero di record. Una dimensione o un conteggio non dimostra che l'intervallo interessato sia ancora ricercabile. Verificare i record locali conservati e gli archivi centrali per tale intervallo e documentare la copertura delle fonti, le lacune nell'inoltro e le prove storiche disponibili su criteri e SACL. Microsoft Learn: Get-WinEvent.

Rispondere esplicitamente alla prima domanda decisionale: quale SACL per la scrittura dell'attributo e quali prove di conservazione supportano questa ricostruzione? Registrare l'oggetto sottoposto ad audit o l'ambito ereditato, l'azione di scrittura pertinente, l'entità di sicurezza coperta e l'impostazione di successo. Se è disponibile soltanto la configurazione attuale, indicare la copertura storica come non dimostrata. Non dedurre che l'assenza di un evento storico significhi che l'attributo non sia mai stato modificato.

Passo 2: recuperare gli eventi senza un limite arbitrario di coppia

Utilizzare un intervallo delimitato che includa la modifica in esame. L'esempio seguente seleziona eventi Security per provider, ID e ora:

$reviewStart = [DateTimeOffset]::Parse('2026-10-04T08:00:00Z').UtcDateTime
$reviewEnd = [DateTimeOffset]::Parse('2026-10-04T09:00:00Z').UtcDateTime
$events = Get-WinEvent -ComputerName 'dc01.contoso.local' -FilterHashtable @{
    LogName = 'Security'
    ProviderName = 'Microsoft-Windows-Security-Auditing'
    Id = 5136
    StartTime = $reviewStart
    EndTime = $reviewEnd
} -ErrorAction Stop

Questi orari sono illustrativi, non una finestra di modifica misurata o una durata prescritta della revisione. Get-WinEvent documenta queste chiavi di filtro e restituisce i record degli eventi, per impostazione predefinita dal più recente. L'esempio intenzionalmente non richiede solo due eventi né limita il risultato con -MaxEvents. Conservare la query e l'esito prima di selezionare l'oggetto e l'attributo dall'XML dell'evento. Microsoft Learn: parametri di filtro di Get-WinEvent.

Aspettarsi zero o più record corrispondenti, non un numero predeterminato. Se il comando non trova eventi corrispondenti, distinguere tale risultato dagli errori di accesso o connessione, quindi valutare la copertura di conservazione e generazione. Cercare negli archivi autorizzati se necessario; il cmdlet documenta anche -Path per i file di eventi salvati. Una lettura fallita deve restare visibile nel registro del caso.

Conservare l'esportazione originale degli eventi e l'XML di ciascun evento. Uno screenshot del valore più recente non basta per la ricostruzione. In un SIEM, verificare che l'acquisizione preservi i campi seguenti e mantenga l'identità dell'evento sorgente separata dall'ora di acquisizione e da eventuali copie duplicate inoltrate.

Passo 3: assemblare il registro della modifica dell'attributo

Utilizzare ObjectGUID per identificare l'oggetto e AttributeLDAPDisplayName per identificare l'attributo. Registrare DN e classe come contesto. Raccogliere quindi tutti gli eventi di valore candidati che condividono l'ID di correlazione dell'operazione per quell'oggetto e attributo, verificando DC emittente, soggetto e orari. Se questi campi non concordano, mantenere la discrepanza per l'indagine invece di forzare i record in una sola coppia.

Questi nomi dei campi dell'evento provengono dall'XML di 5136 e dalle descrizioni dei campi. I campi di approvazione sono un registro di revisione proposto, non telemetria Windows aggiuntiva.

Per una sostituzione a valore singolo con prove complete, il revisore dovrebbe poter descrivere l'eliminazione e l'aggiunta osservate e fare riferimento a ciascun record sorgente. Per un attributo multivalore, conservare le singole rimozioni e aggiunte come insiemi di operazioni osservate. Non inventare valori rimasti invariati né affermare che l'insieme degli eventi sia un'istantanea completa prima e dopo la modifica.

Per il confronto con lo stato attuale della directory, Get-ADObject accetta un GUID dell'oggetto come -Identity, attributi aggiuntivi come -Properties e un server specifico come -Server. Questo esempio utilizza il GUID dell'evento 5136 di esempio di Microsoft; sostituirlo, insieme all'attributo di esempio, con gli identificatori in esame.

Get-ADObject -Identity '4fe80a66-5f93-4f73-b215-68678058e613' -Server 'dc01.contoso.local' -Properties userAccountControl -ErrorAction Stop

Aspettarsi l'oggetto individuato e la proprietà richiesta, oppure un errore esplicito di lettura o ricerca. Conservare l'ora di raccolta e il DC. Lo stato attuale può aiutare a convalidare la correzione, ma non può recuperare un valore storico o un'approvazione mancanti. Microsoft Learn: Get-ADObject.

Verifica: rendere indipendente la decisione di approvazione

Chiedere all'autorità designata per le modifiche di associare la richiesta a questo oggetto, attributo e cambiamento di valore previsto. Registrare chi è autorizzato a decidere, le prove di approvazione e la loro ora, e se tali prove coprono l'operazione osservata. Un operatore che spiega una modifica fornisce prove utili, ma una spiegazione non è automaticamente un'approvazione indipendente.

Mantenere l'attore tecnico e il decisore in campi separati. Se un account di automazione ha richiesto la modifica, registrare tale soggetto senza ipotizzare l'iniziatore umano. Stabilire qualsiasi attribuzione a un operatore attraverso registri indipendenti. Allo stesso modo, non associare una richiesta aziendale a un evento solo perché i timestamp sono vicini o entrambe le descrizioni menzionano una «manutenzione della directory».

Classificare esplicitamente i casi difficili:

Questa tabella propone esiti di revisione. Non afferma che ogni evento senza corrispondenza sia malevolo. Rispondere alle domande decisionali rimanenti prima della chiusura: chi conferma l'autorizzazione indipendentemente dall'attore tecnico e come verranno qualificate le prove mancanti, multivalore o di sola eliminazione? Assegnare a ciascun elemento irrisolto un responsabile e la prossima richiesta di prove.

Correzione: risolvere la decisione e convalidare la copertura (Remediation)

Conservare le prove storiche prima di apportare una modifica correttiva alla directory. Per una modifica approvata supportata da prove, allegare la decisione al registro di revisione. Per una discrepanza nell'approvazione o una modifica non autorizzata confermata, chiedere ai responsabili dell'identità e dei servizi coinvolti di valutare esposizione e dipendenze, decidere il contenimento o la correzione e registrare lo stato obiettivo autorizzato. Evitare di ripristinare alla cieca un valore eliminato: modifiche legittime successive o dipendenze multivalore possono rendere tale azione errata.

Se la copertura di generazione è inadeguata, gli amministratori autorizzati devono correggere i criteri di audit applicabili e la SACL di scrittura dell'attributo. Microsoft documenta l'audit dei successi per Directory Service Changes e l'assenza di eventi Failure in questa sottocategoria. Eseguire il comando seguente localmente sul DC selezionato. Utilizza la sintassi documentata auditpol /set per abilitare l'audit dei successi, modifica la configurazione e rientra in una procedura amministrativa approvata.

auditpol /set /subcategory:"Directory Service Changes" /success:enable

Un esito positivo del comando è seguito dalla lettura auditpol /get precedente e dalla SACL corrispondente verificata separatamente. Il comando non configura una SACL, non dimostra la persistenza dei criteri gestiti centralmente e non ricrea gli eventi passati. Coordinarlo con il responsabile dei criteri e conservare le prove di configurazione risultanti. Microsoft Learn: auditpol set, Audit Directory Service Changes.

Convalidare la copertura futura attraverso una modifica pilota approvata su un oggetto di test non in produzione e un attributo adatto. Registrare l'intento autorizzato sui vecchi e nuovi valori prima del test. Verificare che gli eventi generati e conservati contengano l'oggetto, l'attributo e le operazioni di valore attesi, che l'inoltro ne preservi l'identità e che la revisione possa collegarli all'approvazione del test. Per questo articolo non è stato eseguito alcun test di questo tipo su un dominio.

Dopo una correzione autorizzata, ripetere la lettura dell'oggetto nell'ambito definito e la revisione degli eventi. Conservare lo stato attuale, le prove dell'operazione correttiva e la decisione indipendente. Chiudere soltanto le parti del caso supportate dalle prove; mantenere le lacune della ricostruzione storica con un esito documentato.

Come EtcSec rileva questo problema

Al commit del raccoglitore bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, CHANGE_MANAGEMENT_BYPASS è un'euristica di postura di gravità Medium. Il suo Detect() legge gli utenti LDAP raccolti. Conta gli utenti abilitati le cui voci dirette memberOf contengono i nomi inglesi Domain Admins o Enterprise Admins, utilizzando una corrispondenza di sottostringhe senza distinzione tra maiuscole e minuscole. Più di 10 utenti di questo tipo genera un problema. Un conteggio separato include gli utenti con almeno un SPN e adminCount=1; più di 5 genera un altro problema. Il secondo conteggio non esclude gli utenti disabilitati.

Se una delle condizioni è soddisfatta, la segnalazione restituita ha Count=1; altrimenti ha Count=0. Uno è l'indicatore della segnalazione, non il numero di modifiche non approvate. I dettagli includono i due contatori aggregati. Le soglie sono euristiche del prodotto senza autorità normativa, non requisiti di approvazione di Microsoft, ANSSI o HDS.

Il provider LDAP fornisce memberOf, servicePrincipalName e adminCount. Questo rilevatore non espande l'appartenenza ai gruppi annidati. I nomi dei gruppi privilegiati rinominati o localizzati possono impedire la corrispondenza con il nome inglese; la corrispondenza di sottostringhe non è un test stabile del SID del gruppo. Microsoft documenta che adminCount può restare impostato a 1 dopo che un account lascia un gruppo protetto; questo flag non stabilisce quindi il privilegio effettivo attuale. Un SPN può essere registrato su un account utente o computer, quindi la sua sola presenza non stabilisce lo scopo operativo attuale dell'account. Microsoft Learn: account protetti e adminCount, registrazione degli SPN. Anche l'ambito e i limiti della raccolta vincolano le popolazioni esaminate.

Questo controllo non legge eventi 5136, valori rimossi o aggiunti, ID di correlazione, SACL, registri di conservazione o flussi di approvazione. Una segnalazione positiva può avviare una revisione della gestione delle modifiche, ma non può dimostrare un aggiramento, identificare questa modifica dell'attributo o decidere l'autorizzazione. Un conteggio pari a zero non può convalidare il registro delle prove. Completare la ricostruzione degli eventi e la decisione indipendente descritte sopra prima di chiudere la revisione.