Utilizzo pratico in un ambiente di dominio (raccolta e conversione guidate da GPO)

Questo esempio dimostra come implementare un flusso di lavoro guidato da GPO per la raccolta e la conversione dei log di debug DNS sui controller di dominio.

For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /it/docs/examples/gpo-driven-collection/index.md.

Questo documento illustra un esempio pratico, end-to-end, di esecuzione di DNSServer.DebugLogParser in un ambiente di dominio Active Directory, focalizzato sulla conversione dei log di debug del server DNS di Windows sui controller di dominio.

Questo esempio è accompagnato da un archivio ZIP, che fornisce gli artefatti di policy utilizzati per implementare il flusso di lavoro descritto qui.
Gli artefatti più rilevanti sono il manifest di backup, il report GPO, il Files.xml, lo Set-DNSServerDebugLogging.ps1 e il ScheduledTasks.xml.

Scenario

  • Più controller di dominio (DC) ospitano il ruolo DNS Server.
  • Il logging di debug DNS è abilitato e configurato in modo coerente su ogni DC tramite un’attività pianificata (che scrive i file di log in C:\Administration\Logs\DNSServer).
  • Un processo gestito centralmente converte i log in CSV per:
    • analisi di sicurezza
    • report operativi
    • risoluzione dei problemi
    • conformità/conservazione

Obiettivi

  • Impostazioni di conversione coerenti su tutti i DC
  • Posizione e denominazione dell’output prevedibili
  • Compressione opzionale per ridurre lo spazio di archiviazione
  • Output statistici opzionali per riepiloghi giornalieri rapidi
  • Rischio minimo sul lato host, con considerazioni esplicite su riesecuzione e pulizia

Architettura suggerita

Modello di raccolta: conversione locale + raccolta centrale

  1. Ogni DC scrive i log di debug DNS su disco con rollover abilitato.
  2. Ogni DC converte i file *.log ruotati in un CSV dati e CSV statistici, quindi comprime gli output in *.zip secondo una pianificazione (Utilità di pianificazione).
  3. Gli output sono scritti accanto ai file di log per mantenere semplice la pipeline.
  4. Un server centrale raccoglie gli output *.zip, ad esempio tramite condivisione file, copia pianificata, inoltro SIEM o un collector basato su agente.

Questo modello minimizza le letture di rete di grandi file di log grezzi e mantiene l’analisi vicino ai dati.

Flusso di lavoro GPO

Il flusso di lavoro è implementato tramite Criteri di gruppo (configurazione computer) per garantire impostazioni coerenti su tutti i controller di dominio.

Implementazione di riferimento inclusa in questo repository (report GPO):

  • Nome archivio/report: T0-C-Analytics-DNSDebugLogging
  • ID backup: {2B6F16BC-0E7C-4787-83D7-2854FED882EE}
  • Target link GPO: corp.company.com/Domain Controllers
  • Filtro elementi (usato sia per il deployment dei file che per le attività pianificate): si applica solo se esiste C:\Windows\System32\dns.exe

1) Prerequisiti (cartelle + modulo)

Il backup fornito presuppone che queste cartelle esistano già. Aggiungi elementi GPP separati se vuoi che il deployment le crei automaticamente:

  • C:\Administration\Scripts
  • C:\Administration\Logs\DNSServer

Il backup fornito presuppone anche che Convert-DNSDebugLogFile sia già disponibile sui DC. L’attività di conversione avvia Windows PowerShell 5.1 con -NoProfile e non importa esplicitamente il modulo, quindi il modulo deve essere installato in un percorso modulo PowerShell a livello macchina visibile a LocalSystem. Approcci consigliati:

  • Installa DNSServer.DebugLogParser sui DC. Ad esempio, da PowerShell Gallery (se la policy lo consente).
  • Distribuisci il modulo tramite repository interno/condivisione file così che sia rilevabile in $env:PSModulePath
  • Aggiungi un esplicito Import-Module all’azione dell’attività se vuoi un comportamento di caricamento deterministico

2) Distribuire lo script di configurazione del debug logging (GPP Files)

La GPO distribuisce lo script:

  • Sorgente (in SYSVOL tramite GPP): %GptPath%\Preferences\Files\Set-DNSServerDebugLogging.ps1
  • Destinazione (su ogni DC): C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1

Questo è implementato nell’elemento preferenze GPP Files in Files.xml.

3) Attività pianificata: configurare il debug logging DNS

La GPO crea un’attività pianificata chiamata Set-DNSServerDebugLogging.

  • Contesto di sicurezza nel backup fornito: SYSTEM con tipo di accesso S4U
  • Trigger nel backup fornito: giornaliero (inizio 2025-03-01T00:00:01)
  • Azione in ScheduledTasks.xml:
    • powershell.exe -ExecutionPolicy RemoteSigned -command " & { C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1 }"
    • Directory di lavoro: C:\Administration\Scripts

Lo script Set-DNSServerDebugLogging.ps1 configura il debug logging DNS tramite Get-DnsServerDiagnostics / Set-DnsServerDiagnostics e (in particolare):

  • Abilita il logging su file + rollover
  • Scrive in: C:\Administration\Logs\DNSServer\DnsDebugLog_<COMPUTERNAME>.<Domain>_.log
  • Usa una dimensione di rollover di 10 MB per file
  • Cattura principalmente attività correlate alle query (query + notifiche + aggiornamenti + transazioni di domanda) ed esclude il logging completo dei pacchetti

4) Attività pianificata: convertire i log di debug ruotati in CSV compressi

La GPO crea un’attività pianificata chiamata Convert-DNSDebugLogs.

  • Contesto di sicurezza nel backup fornito: SYSTEM con tipo di accesso InteractiveToken
  • Trigger nel backup fornito: giornaliero (inizio 2026-01-01T00:30:00)
  • Directory di lavoro: C:\Administration\Logs\DNSServer
  • Azione in ScheduledTasks.xml (formattata per leggibilità):
Get-ChildItem .\*.log |
  Sort-Object lastwritetime, Name -Descending |
  Select-Object -Skip 1 |
  Convert-DNSDebugLogFile `
    -ComputerName $env:COMPUTERNAME `
    -Delimiter ';' `
    -OutputType Both `
    -ContextFilter Packet `
    -OutputCulture sv-SE `
    -CompressOutput

Note di progettazione:

  • Select-Object -Skip 1 evita intenzionalmente di processare il file di log più recente (attivo). Convert-DNSDebugLogFile è in grado di leggere un log che DNS Server ha attualmente aperto, ma quel file cambia mentre viene letto: l’output può mancare le voci più recenti o terminare con un record troncato, e due esecuzioni non producono risultati identici. Saltare il file attivo mantiene l’output pianificato riproducibile.
  • Ciò significa che i dati correnti vengono esportati solo dopo il rollover; su DC a basso volume, il log attivo può rimanere non processato per più di un giorno. Riduci la dimensione di rollover se questo ritardo è troppo lungo per il tuo caso d’uso.
  • Poiché Convert-DNSDebugLogFile imposta di default -OutputFile su “stessa cartella, stesso nome, .csv”, gli output finiscono accanto agli input *.log.
  • Con -CompressOutput, ogni log processato produce un *.zip e i CSV intermedi vengono rimossi.
  • A meno che non archivi o elimini i file *.log processati, le esecuzioni successive rielaboreranno ogni log non attivo.
  • L’attività genera un errore se $Error.Count -gt 0 per segnalare un’esecuzione fallita.

5) Ingestione centrale

Opzioni (scegli una):

  • Ingestione da condivisione file: il DC scrive (o copia) C:\Administration\Logs\DNSServer\*.zip in \\fileserver\share\dns\$env:COMPUTERNAME\... (concedi diritti di condivisione e NTFS agli account computer DC o al gruppo Domain Controllers se l’attività gira come SYSTEM)
  • Modello pull: lavoro centrale legge \\dc\C$\Administration\Logs\DNSServer\*.zip (meno preferito; richiede condivisioni amministrative)
  • Inoltro agente: SIEM / pipeline di log che spedisce gli output *.zip

Considerazioni operative

  • Privilegi minimi: le attività girano come SYSTEM; assicurati che le cartelle locali siano scrivibili e che eventuali destinazioni UNC concedano accesso all’account computer se usate.
  • Policy di firma: entrambe le attività usano -ExecutionPolicy RemoteSigned; firma o sblocca lo script e il modulo distribuiti secondo la tua policy.
  • Uso disco: -CompressOutput aiuta significativamente, ma questo flusso di lavoro non rimuove i log sorgente; pianifica conservazione e pulizia.
  • Comportamento di rielaborazione: a meno che non archivi o elimini i log processati, l’attività di conversione processerà ogni file *.log non attivo di nuovo nelle esecuzioni successive. È semplice e robusto, ma può sovrascrivere output e creare duplicati a valle se il tuo collector non fa deduplicazione.
  • Consolidamento multi-DC: -ComputerName $env:COMPUTERNAME è incluso così i dataset consolidati rimangono tracciabili. Nota che -ComputerName etichetta solo l’output — non esegue connessioni remote.
  • Condivisioni di rete: Convert-DNSDebugLogFile può leggere i log sorgente da percorsi SMB/UNC, ma convertire localmente e spedire i risultati compressi rimane il modello migliore per log grezzi grandi. Se usi un percorso UNC, ricorda che un’attività che gira come SYSTEM si autentica in rete come account computer e necessita di diritti di condivisione e NTFS lì.
  • Formato data: -OutputCulture sv-SE è usato deliberatamente così i timestamp sono scritti come 2026-01-20 23:00:16. Quel formato è letto senza ambiguità da SQL Server, Power BI e la maggior parte degli strumenti di importazione, indipendentemente dalla localizzazione del DC che ha prodotto il log.
  • Validazione: la validazione dell’intestazione rimane abilitata perché l’attività non usa -SkipHeaderValidation (consigliato).

Validare e adattare (usando lo ZIP)

Usa l’archivio ZIP come implementazione di riferimento, quindi allinea i seguenti aspetti al tuo ambiente:

  • Ambito target: quali DC / OU ricevono la policy
  • Identità di esecuzione: conferma che entrambe le attività pianificate usino il tipo di accesso previsto (S4U vs InteractiveToken) o normalizzali al tuo standard
  • Creazione cartelle: decidi se C:\Administration\Scripts e C:\Administration\Logs\DNSServer sono pre-creati altrove o devono essere creati da ulteriori elementi GPP
  • Percorsi: conferma che C:\Administration\Scripts e C:\Administration\Logs\DNSServer corrispondano ai tuoi standard
  • Conservazione: decidi se mantenere i log grezzi e per quanto tempo (specialmente se abiliti opzioni di pulizia)
  • Ingestione: conferma dove vengono scritti gli output CSV/ZIP e come vengono raccolti centralmente

Se vuoi validare la configurazione esatta della GPO senza importarla, le fonti autorevoli in questo repo sono: