Metadati GPO AD: verificare i filtri WMI con un report mirato

Che cos'è una revisione dei metadati GPO AD?

Una revisione dei metadati GPO AD confronta un inventario raccolto degli oggetti Criteri di gruppo con informazioni recuperate in modo indipendente per lo stesso criterio, dominio e controller di dominio. Il risultato è un registro di ciò che è stato letto, di ciò che coincide e di ciò che rimane sconosciuto. La presenza di una GPO in un inventario attesta l'osservazione di un asset; non attesta un filtraggio corretto, una delega completa, versioni sincronizzate o un'applicazione riuscita sui client.

Questa distinzione conta quando un inventario presenta un filtro WMI vuoto o un elenco breve di autorizzazioni. Un campo può essere vuoto perché il percorso di raccolta non lo ha mai richiesto. Considerare quella rappresentazione un'assenza confermata trasforma un limite della raccolta in un verdetto sulla configurazione. Lo stesso problema si presenta quando una lettura dei collegamenti fallita sembra un criterio privo di collegamenti.

La procedura seguente usa l'inventario come punto di partenza e una query Group Policy con ambito definito come riscontro. Propone una revisione operativa, non un audit eseguito sul dominio di un cliente. Non occorre modificare alcun criterio per raccogliere le evidenze di confronto.

Come funziona: mantenere insieme identità e provenienza delle letture

Iniziate con un record identificato dal GUID della GPO e dal dominio. Conservate il nome visualizzato per facilitarne la lettura, ma non usatelo come chiave di corrispondenza. Aggiungete il DC interrogato, l'ora della raccolta, la fonte e l'esito positivo o negativo di ogni lettura. Quando la raccolta originale non espone questi dettagli, indicateli come sconosciuti invece di attribuire il contesto di una sessione PowerShell successiva all'osservazione precedente.

La documentazione di Get-GPO di Microsoft descrive il recupero con -Name, -Guid o -All. Un nome visualizzato duplicato provoca un errore, quindi usate il GUID per la riconciliazione. L'output di esempio include GpoStatus, WmiFilter, UserVersion e ComputerVersion; ogni proprietà di versione mostra i valori AD e SysVol. -Domain accetta un FQDN; -Server seleziona un DC. Omettendoli si utilizzano una selezione del dominio dipendente dalla sessione e l'emulatore PDC.

La documentazione di Get-GPOReport di Microsoft descrive report XML o HTML che contengono collegamenti, filtraggio WMI, filtraggio di sicurezza, delega e impostazioni dei criteri. Sono dati di ingresso per la riconciliazione, non un risultato dell'elaborazione su un client. Per entrambi i cmdlet, interrogare un dominio diverso richiede una relazione di trust con il dominio dell'utente della sessione (il dominio del computer per gli script di avvio o arresto).

Usate un foglio di lavoro che mantenga visibili entrambe le osservazioni:

Aggiungete un riferimento al file di evidenza e un responsabile a ogni confronto non risolto. Una schermata senza GUID o un'esportazione senza il relativo DC deve rimanere un'evidenza incompleta. Questo registro è un artefatto di revisione che costruite voi; il rilevatore dell'inventario non produce tutti questi campi.

La catena di errore: metadati sconosciuti diventano una falsa garanzia

Considerate uno scenario di revisione proposto: una GPO compare nell'inventario, il suo campo WMI è vuoto e i suoi collegamenti e le sue deleghe sembrano ordinari. Chi esegue la revisione conclude che il criterio non ha restrizioni WMI e che il riepilogo dei suoi diritti basta a spiegarne l'applicazione. Un report indipendente mostra poi un'associazione WMI che l'inventario non ha mai raccolto.

Il problema è l'interpretazione delle evidenze. Sostituire il valore vuoto dell'inventario con quello del report migliora il registro di revisione, ma non stabilisce quali client soddisfino il filtro. Analogamente, un riepilogo della delega non permette di risolvere le voci Deny esplicite o di dimostrare chi possa effettivamente modificare il criterio.

Una discrepanza diversa può emergere quando il report e l'inventario sono stati ottenuti da DC diversi o in momenti diversi. Conservate questi contesti prima di definire la differenza una deriva della configurazione. Altrimenti, una differenza di ambito, una lettura fallita o un'osservazione che cambia può essere scambiata per un guasto di replica confermato.

Per la distinta questione dell'applicazione, usate la guida per verificare i diritti Read e Apply delle GPO e l'ambito effettivo dei destinatari. Distingue le autorizzazioni di recupero dai diritti di applicazione e convalida i risultati dei destinatari previsti e non previsti. Questo foglio di metadati fornisce dati contestualizzati a tale indagine.

Per la modifica dei criteri, esaminate i diritti di modifica delle GPO e i collegamenti alle OU Tier 0. Quell'articolo esamina il perimetro delle autorizzazioni della GPO stessa. Una voce di delega nell'inventario è un motivo per ispezionare il soggetto di sicurezza e gli oggetti pertinenti, non la prova di un controllo effettivo su un criterio privilegiato.

Rilevamento: recuperare una GPO e un report con ambito definito

1. Identificare l'oggetto del confronto

Selezionate il GUID reale, il FQDN del dominio e il DC dall'ambito di revisione autorizzato. I valori seguenti sono esempi, non infrastruttura scoperta. Sostituiteli prima dell'uso. Eseguite i comandi in un ambiente di amministrazione con il modulo GroupPolicy disponibile; conservate gli errori insieme agli output riusciti.

Questa query adatta il set di parametri GUID documentato di Get-GPO fornendo sia Domain sia Server:

Get-GPO -Guid '31a09564-cd4a-4520-98fa-446a2af23b4b' -Domain 'sales.contoso.com' -Server 'DC1'

Registrate l'identità restituita, lo stato, le informazioni WMI e le coppie di versioni utente/computer. Copiate i valori effettivi nel foglio di lavoro. Non sostituite una misurazione con l'output di esempio della documentazione Microsoft.

2. Recuperare il report dallo stesso ambito

Questo comando usa il set di parametri GUID documentato di Get-GPOReport. Senza Path, il report viene scritto sul display:

Get-GPOReport -Guid '31a09564-cd4a-4520-98fa-446a2af23b4b' -Domain 'sales.contoso.com' -Server 'DC1' -ReportType XML

Per un confronto più ampio, il seguente è il modello documentato di report di tutte le GPO espresso con parametri espliciti. Usate una directory di output esistente e approvata:

Get-GPOReport -All -Domain 'sales.contoso.com' -Server 'DC1' -ReportType XML -Path 'C:\GPOReports\GPOReportsAll.xml'

Esaminate il report del criterio pertinente fino ai suoi ultimi blocchi di configurazione. Conservate insieme il report e il contesto del comando. Un file di report rimasto da un'esecuzione precedente non dimostra che un comando successivo fallito sia riuscito.

3. Classificare le differenze

La concordanza è utile, ma non estende l'osservazione a ogni DC o a ogni client. Se è approvata la revisione di altri DC, ripetete separatamente le stesse query esplicite e conservate un registro distinto per ciascuno. Un errore di autorizzazione rimane un errore; non deve diventare un conteggio pari a zero o un valore «assente».

Correzione: riparare le evidenze prima di modificare il criterio (Remediation)

1. Correggere le conclusioni non supportate

Sostituite ogni verdetto non supportato «nessun filtro WMI», «nessun collegamento» o «accesso effettivo in modifica» con il corretto stato sconosciuto o non risolto. Allegate le informazioni recuperate in modo indipendente senza sovrascrivere l'osservazione originale. Così si conserva il motivo per cui la revisione è cambiata e il responsabile può distinguere le lacune della raccolta dalle modifiche di configurazione.

2. Indagare i problemi di coerenza

Quando le versioni o le osservazioni con ambito definito non coincidono, avviate un'indagine sulla replica con gli amministratori AD. Fornite il GUID esatto, i DC, i timestamp, le coppie di versioni utente/computer e gli errori di lettura. Richiedete un backup approvato secondo la procedura di ripristino dell'organizzazione prima di qualsiasi riparazione autorizzata. Un report è un'evidenza per la revisione; non sostituisce un backup che consenta il ripristino.

Non modificate i numeri di versione per far superare un confronto, non eliminate una GPO per rimuovere una riga inspiegata dell'inventario e non cambiate un'associazione WMI soltanto per riempire un campo mancante del collector. Il foglio di lavoro deve descrivere il criterio osservato anziché spingere il criterio ad assomigliare a un payload incompleto.

3. Verificare il risultato

Dopo che il team responsabile ha completato una correzione approvata, ripetete Get-GPO e Get-GPOReport con Domain e Server espliciti. Registrate nuovi timestamp e confrontate con la baseline conservata. Chiudete ogni discrepanza con le relative evidenze, il responsabile e la spiegazione; mantenete i limiti della raccolta non risolti.

Se la questione è se le impostazioni si applichino a un utente o computer previsto, richiedete una convalida separata dei risultati sul client. Né metadati coincidenti né la generazione riuscita di un report stabiliscono i criteri risultanti su quel client.

Come EtcSec rileva questo caso

Questa descrizione è limitata a INFO_DOMAIN_GPO_INVENTORY nel commit 9f698083354a1cb7f625df5cb490a515823c3257 di etc-collector. Il suo metodo Detect() emette un riscontro Info con Count=1 per ogni GPO raccolta. I dettagli delle entità interessate vengono allegati solo quando IncludeDetails è abilitato. Se non sono state raccolte GPO, restituisce nil; ciò non dimostra che il dominio sia vuoto.

Il percorso LDAP GetGPOs esaminato non richiede né versionNumber né gPCWQLFilter. GPOEntity imposta esplicitamente WmiFilter su un valore vuoto. Interpretate quel valore come metadati WMI non raccolti, non come prova che non sia associato alcun filtro. Questo controllo d'inventario non fornisce alcuna prova della coerenza delle versioni AD/SYSVOL o dei criteri risultanti sui client.

La raccolta dei collegamenti tenta la ricerca Sites sotto un DN Configuration costruito a partire da BaseDN e ignora l'errore di quella ricerca. Il motore ignora anche gli errori restituiti da GetGPOs, GetGPOLinks e GetGPOAcls. Di conseguenza, asset, collegamenti o voci di delega assenti richiedono una conferma indipendente delle letture riuscite e dell'ambito.

Infine, gpoPermissions raggruppa i diritti per soggetto di sicurezza senza separare le voci Deny o calcolare l'accesso effettivo. Il suo output è un riepilogo da indagare, non un verdetto di autorizzazione. Usate il foglio di lavoro con ambito definito e il confronto del report per contestualizzare queste osservazioni.

INFO_DOMAIN_GPO_INVENTORY è un controllo d'inventario nel collector esaminato. È assente dal catalogo dei tag di vulnerabilità del sito, quindi questo articolo non presenta tag di vulnerabilità. Il suo scopo è aiutare chi esegue la revisione a preservare gli aspetti sconosciuti e riconciliare i metadati delle GPO prima di prendere una decisione operativa.