Utilisation pratique dans un environnement de domaine (collection et conversion pilotées par GPO)

Cet exemple montre comment mettre en œuvre un flux de travail piloté par GPO pour collecter et convertir les journaux de débogage DNS sur les contrôleurs de domaine.

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

Ce document présente un exemple pratique complet d’exécution de DNSServer.DebugLogParser dans un environnement de domaine Active Directory, axé sur la conversion des journaux de débogage du serveur DNS Windows sur les contrôleurs de domaine.

Cet exemple est accompagné d’une archive ZIP, qui fournit les artefacts de stratégie utilisés pour mettre en œuvre le flux de travail décrit ici.
Les artefacts les plus pertinents sont le manifest de sauvegarde, le rapport GPO, le Files.xml, le Set-DNSServerDebugLogging.ps1, et le ScheduledTasks.xml.

Scénario

  • Plusieurs contrôleurs de domaine (DC) hébergent le rôle de serveur DNS.
  • Le journal de débogage DNS est activé et configuré de manière cohérente sur chaque DC via une tâche planifiée (écriture des fichiers journaux dans C:\Administration\Logs\DNSServer).
  • Un processus centralisé convertit les journaux en CSV pour :
    • l’analyse de sécurité
    • le reporting opérationnel
    • le dépannage
    • la conformité / conservation

Résultats visés

  • Paramètres de conversion cohérents sur tous les DC
  • Emplacement et nommage des fichiers de sortie prévisibles
  • Compression optionnelle pour réduire l’espace de stockage
  • Sorties statistiques optionnelles pour des synthèses quotidiennes rapides
  • Risque minimal côté hôte, avec des considérations explicites de relance et nettoyage

Architecture suggérée

Modèle de collecte : conversion locale + collecte centrale

  1. Chaque DC écrit les journaux de débogage DNS sur disque avec rotation activée.
  2. Chaque DC convertit les fichiers *.log archivés en CSV de données et CSV statistiques, puis compresse les sorties en *.zip selon un planning (Planificateur de tâches).
  3. Les sorties sont écrites à côté des fichiers journaux pour garder le pipeline simple.
  4. Un serveur central collecte les fichiers *.zip, par exemple via ingestion de partage de fichiers, copie planifiée, forwarder SIEM ou collecteur basé agent.

Ce modèle minimise les lectures réseau de gros fichiers journaux bruts et maintient l’analyse proche des données.

Flux de travail GPO

Le flux de travail est mis en œuvre via la stratégie de groupe (configuration ordinateur) pour garantir des paramètres cohérents sur tous les contrôleurs de domaine.

Implémentation de référence incluse dans ce dépôt (rapport GPO) :

  • Nom d’archive/rapport : T0-C-Analytics-DNSDebugLogging
  • ID de sauvegarde : {2B6F16BC-0E7C-4787-83D7-2854FED882EE}
  • Cible de lien GPO : corp.company.com/Domain Controllers
  • Filtre d’élément (utilisé pour le déploiement des fichiers et les tâches planifiées) : s’applique uniquement si C:\Windows\System32\dns.exe existe

1) Prérequis (dossiers + module)

La sauvegarde fournie suppose que ces dossiers existent déjà. Ajoutez des éléments GPP séparés si vous souhaitez que le déploiement les crée automatiquement :

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

La sauvegarde fournie suppose également que Convert-DNSDebugLogFile est déjà disponible sur les DC. La tâche de conversion lance Windows PowerShell 5.1 avec -NoProfile et n’importe pas explicitement le module, donc celui-ci doit être installé dans un chemin de module PowerShell machine-wide visible par LocalSystem. Approches recommandées :

  • Installer DNSServer.DebugLogParser sur les DC. Par exemple, depuis PowerShell Gallery (si la politique le permet).
  • Déployer le module via un repo interne / partage de fichiers pour qu’il soit détectable dans $env:PSModulePath
  • Ajouter un Import-Module explicite à l’action de la tâche si vous souhaitez un chargement déterministe

2) Déployer le script de configuration du journal de débogage (GPP Files)

La GPO déploie le script :

  • Source (dans SYSVOL via GPP) : %GptPath%\Preferences\Files\Set-DNSServerDebugLogging.ps1
  • Cible (sur chaque DC) : C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1

Cela est implémenté dans l’élément de préférence GPP Files dans Files.xml.

3) Tâche planifiée : configurer le journal de débogage DNS

La GPO crée une tâche planifiée nommée Set-DNSServerDebugLogging.

  • Contexte de sécurité dans la sauvegarde fournie : SYSTEM avec type de connexion S4U
  • Déclencheur dans la sauvegarde fournie : quotidien (heure de début 2025-03-01T00:00:01)
  • Action dans ScheduledTasks.xml :
    • powershell.exe -ExecutionPolicy RemoteSigned -command " & { C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1 }"
    • Répertoire de travail : C:\Administration\Scripts

Le script Set-DNSServerDebugLogging.ps1 configure le journal de débogage DNS via Get-DnsServerDiagnostics / Set-DnsServerDiagnostics et notamment :

  • Active la journalisation dans un fichier + rotation
  • Écrit dans : C:\Administration\Logs\DNSServer\DnsDebugLog_<COMPUTERNAME>.<Domain>_.log
  • Utilise une taille de rotation de 10 Mo par fichier
  • Capture principalement l’activité liée aux requêtes (requêtes + notifications + mises à jour + transactions de questions) et exclut la journalisation complète des paquets

4) Tâche planifiée : convertir les journaux de débogage archivés en CSV compressé

La GPO crée une tâche planifiée nommée Convert-DNSDebugLogs.

  • Contexte de sécurité dans la sauvegarde fournie : SYSTEM avec type de connexion InteractiveToken
  • Déclencheur dans la sauvegarde fournie : quotidien (heure de début 2026-01-01T00:30:00)
  • Répertoire de travail : C:\Administration\Logs\DNSServer
  • Action dans ScheduledTasks.xml (formaté pour la lisibilité) :
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

Notes de conception :

  • Select-Object -Skip 1 évite intentionnellement de traiter le fichier journal le plus récent (actif). Convert-DNSDebugLogFile peut lire un journal que le serveur DNS a actuellement ouvert, mais ce fichier change pendant la lecture : la sortie peut manquer les entrées les plus récentes ou se terminer par un enregistrement tronqué, et deux exécutions ne produisent pas des résultats identiques. Ignorer le fichier actif maintient la sortie planifiée reproductible.
  • Cela signifie que les données actuelles ne sont exportées qu’après la rotation ; sur les DC à faible volume, le journal actif peut rester non traité plus d’un jour. Réduisez la taille de rotation si ce délai est trop long pour votre cas d’usage.
  • Parce que Convert-DNSDebugLogFile utilise par défaut -OutputFile « même dossier, même nom, .csv », les sorties se trouvent à côté des entrées *.log.
  • Avec -CompressOutput, chaque journal traité produit un *.zip et les CSV intermédiaires sont supprimés.
  • À moins d’archiver ou supprimer les fichiers *.log traités, les exécutions ultérieures retraiteront tous les journaux non actifs.
  • La tâche génère une erreur si $Error.Count -gt 0 pour signaler un échec.

5) Ingestion centrale

Options (choisir une) :

  • Ingestion via partage de fichiers : le DC écrit (ou copie) C:\Administration\Logs\DNSServer\*.zip vers \\fileserver\share\dns\$env:COMPUTERNAME\... (accorder les droits de partage et NTFS aux comptes ordinateurs DC ou au groupe Domain Controllers si la tâche s’exécute en SYSTEM)
  • Modèle pull : un job central lit \\dc\C$\Administration\Logs\DNSServer\*.zip (moins recommandé ; nécessite les partages admin)
  • Forwarder agent : pipeline SIEM / journal qui expédie les sorties *.zip

Considérations opérationnelles

  • Moindre privilège : les tâches s’exécutent en SYSTEM ; assurez-vous que les dossiers locaux sont accessibles en écriture et que toute cible UNC accorde l’accès au compte ordinateur si utilisée.
  • Politique de signature : les deux tâches utilisent -ExecutionPolicy RemoteSigned ; signez ou débloquez le script et le module déployés selon votre politique.
  • Utilisation disque : -CompressOutput aide significativement, mais ce flux ne supprime pas les journaux sources ; planifiez la conservation et le nettoyage.
  • Comportement de retraitement : sauf archivage ou suppression des journaux traités, la tâche de conversion retraitera chaque fichier *.log non actif lors des exécutions ultérieures. C’est simple et robuste, mais cela peut écraser les sorties et créer des doublons en aval si votre collecteur ne déduplique pas.
  • Consolidation multi-DC : -ComputerName $env:COMPUTERNAME est inclus pour que les jeux de données consolidés restent traçables. Notez que -ComputerName ne fait que marquer la sortie — il n’établit aucune connexion distante.
  • Partages réseau : Convert-DNSDebugLogFile peut lire les journaux sources depuis des chemins SMB/UNC, mais convertir localement et expédier les résultats compressés reste la meilleure pratique pour les gros journaux bruts. Si vous utilisez un chemin UNC, rappelez-vous qu’une tâche s’exécutant en SYSTEM s’authentifie sur le réseau en tant que compte ordinateur et nécessite les droits de partage et NTFS.
  • Format de date : -OutputCulture sv-SE est utilisé délibérément pour que les horodatages s’écrivent sous la forme 2026-01-20 23:00:16. Ce format est lu sans indication par SQL Server, Power BI et la plupart des outils d’import, indépendamment de la locale du DC qui a produit le journal.
  • Validation : la validation de l’en-tête reste activée car la tâche n’utilise pas -SkipHeaderValidation (recommandé).

Valider et adapter (avec le ZIP)

Utilisez l’archive ZIP comme implémentation de référence, puis alignez les aspects suivants à votre environnement :

  • Portée cible : quels DC / OU reçoivent la stratégie
  • Identité d’exécution : confirmez que les deux tâches planifiées utilisent le type de connexion prévu (S4U vs InteractiveToken) ou normalisez-les selon votre standard
  • Création des dossiers : décidez si C:\Administration\Scripts et C:\Administration\Logs\DNSServer sont pré-créés ailleurs ou doivent être créés par des éléments GPP supplémentaires
  • Chemins : confirmez que C:\Administration\Scripts et C:\Administration\Logs\DNSServer correspondent à vos standards
  • Conservation : décidez si vous conservez les journaux bruts et pour combien de temps (surtout si vous activez les options de nettoyage)
  • Ingestion : confirmez où les sorties CSV/ZIP sont écrites et comment elles sont collectées centralement

Si vous souhaitez valider la configuration exacte de la GPO sans l’importer, les sources autoritaires dans ce dépôt sont :