Policy Analyzer et LGPO : comparer, tester, appliquer

Le guide pilier sur les référentiels de sécurité présente le Microsoft Security Compliance Toolkit et ses deux utilitaires. Ce guide détaille leur usage au quotidien : Policy Analyzer pour répondre à la question « qu'est-ce qui diffère, et où ? », et LGPO.exe pour appliquer, exporter et inspecter la stratégie locale. Ensemble, ils constituent le moyen le plus rapide de tester un référentiel sur une machine avant qu'il n'atteigne une GPO, et de prouver à un auditeur ce qu'une machine applique réellement.

Les deux outils se téléchargent gratuitement depuis la page Security Compliance Toolkit du Centre de téléchargement Microsoft et fonctionnent sur Windows 11 et Windows Server 2016 et versions ultérieures. Téléchargez en même temps les paquets de référentiel actuels ; chacun contient des sauvegardes de GPO, des tableurs de documentation et un dossier Scripts qui attend LGPO.exe dans Scripts\Tools.

Ce que chaque outil lit et écrit

Étape 1 : constituer des ensembles de règles dans Policy Analyzer

Lancez PolicyAnalyzer.exe et cliquez sur Add. Le Policy File Importer permet d'ajouter des fichiers individuels ou un dossier de sauvegarde de GPO entier (File > Add files from GPO(s)), puis d'enregistrer la combinaison comme ensemble .PolicyRules nommé. Constituez-en au moins trois :

1. Baseline : les GPO du référentiel Microsoft pour votre OS et votre rôle, par exemple les GPO ordinateur et utilisateur de Windows 11 24H2, plus les référentiels Edge et Microsoft 365 Apps.
2. Current : une sauvegarde de chaque GPO qui s'applique à l'UO cible. Exportez-les avec Backup-GPO, ou toutes à la fois :

New-Item -ItemType Directory C:\GPOBackup\Workstations -Force | Out-Null
(Get-GPInheritance -Target 'OU=Workstations,DC=corp,DC=example').InheritedGpoLinks |
  ForEach-Object { Backup-GPO -Guid $_.GpoId -Path C:\GPOBackup\Workstations }

3. Previous baseline : la dernière version que vous avez déployée, pour la comparer à une nouvelle publication.

Stockez les fichiers .PolicyRules dans le contrôle de source, à côté de votre registre des écarts. Ce sont de petits fichiers XML qui constituent d'excellentes preuves.

Étape 2 : comparer et lire la grille

Sélectionnez deux ensembles de règles ou plus et cliquez sur View / Compare. Chaque ligne correspond à un paramètre ; chaque colonne affiche sa valeur dans un ensemble. Filtrez la vue avec Show only differences ou Show only conflicts :

• Un conflit est un même paramètre avec des valeurs différentes dans deux ensembles. Entre Baseline et Current, chaque conflit est soit un écart à corriger, soit une dérogation à documenter.
• Un paramètre présent dans Current mais absent de Baseline n'est pas forcément une erreur : les référentiels Microsoft omettent les paramètres dont la valeur par défaut est déjà sûre. Vérifiez toutefois ceux qui affaiblissent une valeur par défaut, comme la réactivation de SMBv1, des hachages LM ou de WDigest (voir ouvertures de session mises en cache et WDigest).
• Un même paramètre défini dans plusieurs de vos GPO, même avec la même valeur, est un risque de maintenance. Consolidez.

Utilisez Export > Export table to Excel pour partager le résultat. Pour une nouvelle publication de référentiel, comparez Previous et New : la différence constitue votre liste de changements, plus courte que la lecture intégrale des notes de publication.

Étape 3 : comparer avec l'état effectif

C'est le mode le plus utile pour les audits : exécutez Policy Analyzer en tant qu'administrateur sur la machine cible, sélectionnez l'ensemble Baseline et cochez Compare to Effective State. Policy Analyzer lit les valeurs de stratégie du registre, les paramètres de sécurité et la stratégie d'audit actuels de la machine, et les ajoute sous forme de colonne.

Cela révèle ce que les revues de GPO manquent :

• Des paramètres modifiés par des scripts, des programmes d'installation ou des administrateurs locaux.
• Des GPO qui ne s'appliquent pas à cause de filtres WMI, d'un filtrage de sécurité ou d'un ordinateur placé dans la mauvaise UO.
• Des valeurs fournies par la MDM, qui apparaissent dans l'état effectif alors qu'aucune GPO ne les définit.

Enregistrez l'état effectif comme ensemble .PolicyRules à part, avec le nom de la machine et la date. Deux instantanés de la même machine à un mois d'intervalle constituent une vérification rapide de la dérive ; le guide sur la dérive de configuration explique comment l'automatiser.

Étape 4 : appliquer un référentiel localement avec LGPO

Sur une VM de laboratoire, un serveur autonome ou une image de référence, appliquez directement les sauvegardes de GPO du référentiel dans la stratégie locale :

# Appliquer chaque sauvegarde de GPO trouvée sous le dossier
.\LGPO.exe /g "C:\SCT\Windows 11 v24H2 Security Baseline\GPOs"

# Ou appliquer des composants individuels
.\LGPO.exe /m C:\Policy\machine-registry.pol     # registry.pol ordinateur
.\LGPO.exe /u C:\Policy\user-registry.pol        # registry.pol utilisateur
.\LGPO.exe /s C:\Policy\GptTmpl.inf              # modèle de sécurité
.\LGPO.exe /a C:\Policy\audit.csv                # stratégie d'audit avancée
.\LGPO.exe /p C:\Policy\Baseline.PolicyRules     # un ensemble de règles Policy Analyzer

Les paquets de référentiel fournissent aussi Baseline-LocalInstall.ps1 dans le dossier Scripts, qui applique la bonne combinaison de GPO avec LGPO et accepte des commutateurs pour les machines jointes ou non au domaine. Exécutez Get-Help .\Baseline-LocalInstall.ps1 -Detailed pour voir les options de votre version de paquet ; l'option pour machines non jointes au domaine ignore les paramètres qui bloqueraient l'administration à distance d'une machine autonome.

Redémarrez après l'application, car plusieurs paramètres de sécurité (par exemple les paramètres LSA et ceux relatifs aux identifiants) ne prennent effet qu'au démarrage.

Étape 5 : exporter et modifier la stratégie locale sous forme de texte

LGPO peut sauvegarder la stratégie locale sous forme de sauvegarde de GPO, que vous pouvez ensuite importer dans une GPO de domaine ou dans Policy Analyzer :

.\LGPO.exe /b C:\Export /n "Lab build - local policy"

Pour lire ou modifier un registry.pol, convertissez-le au format texte de LGPO, modifiez-le, puis appliquez le fichier texte :

.\LGPO.exe /parse /m C:\Windows\System32\GroupPolicy\Machine\Registry.pol > C:\Temp\machine.txt
.\LGPO.exe /t C:\Temp\machine.txt

Le format texte compte quatre lignes par paramètre (configuration, clé, nom de valeur, type et données), séparées par une ligne vide :

Computer
Software\Policies\Microsoft\Windows NT\DNSClient
EnableMulticast
DWORD:0

Utilisez DELETE à la place d'un type pour supprimer une valeur. C'est aussi un moyen pratique de construire une petite stratégie locale pour un serveur de rebond ou une borne sans domaine, et de la conserver dans le contrôle de source.

Étape 6 : superposer vos écarts pour le domaine

Une fois un référentiel testé localement, transposez-le dans le domaine en deux couches : les GPO du référentiel importées sans modification, et une GPO distincte de priorité supérieure ne contenant que vos écarts. Construisez cette GPO d'écarts de façon délibérée :

1. Dans Policy Analyzer, comparez l'ensemble Baseline à l'état effectif d'une machine pilote testée sur laquelle vous avez appliqué vos exceptions.
2. Les différences correspondent exactement à vos écarts. Confrontez chacun au registre des écarts ; tout ce qui n'y est pas documenté est soit un accident, soit une décision non documentée.
3. Créez la GPO d'écarts avec ces seuls paramètres, sauvegardez-la et ajoutez la sauvegarde comme ensemble de règles à part, pour que les comparaisons futures affichent côte à côte référentiel, écarts et état effectif.

Pour un serveur de rebond ou un serveur autonome, procédez de même avec LGPO : appliquez le référentiel avec /g, puis vos écarts avec /t à partir d'un fichier texte conservé dans le contrôle de source. La reconstruction de la machine reproduit alors exactement la même stratégie locale.

Vérifier

Après l'application, confirmez ce que la machine traite réellement :

gpresult /scope computer /h C:\Temp\gpresult.html
auditpol /get /category:* | Out-File C:\Temp\auditpol.txt
secedit /export /cfg C:\Temp\secpol.inf /areas SECURITYPOLICY USER_RIGHTS

Relancez ensuite Policy Analyzer avec Compare to Effective State par rapport à l'ensemble Baseline. Les seules différences restantes doivent être celles de votre registre des écarts. Les erreurs de traitement de la stratégie de groupe apparaissent dans le journal System, source Microsoft-Windows-GroupPolicy (l'événement 1085 signale une extension côté client en échec, 1129 et 1054 pointent généralement vers un problème de connectivité réseau ou avec le DC), et en détail dans Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational.

Ce qui casse

• Les GPO de domaine écrasent LGPO. La stratégie locale est traitée en premier, donc tout ce qui est défini par une GPO de domaine l'emporte. Testez plutôt les paramètres destinés au domaine dans une GPO liée à une UO de laboratoire.
• Le tatouage (tattooing). Les paramètres écrits en dehors des clés de registre Policies (par exemple certaines valeurs MSS héritées et certains paramètres de modèles de sécurité) restent sur la machine lorsque vous retirez la stratégie. Pour les réinitialiser, il faut redéfinir explicitement l'ancienne valeur, pas supprimer la stratégie.
• S'enfermer dehors sur un serveur autonome. Le référentiel pour machines jointes au domaine refuse l'ouverture de session réseau aux comptes locaux. Sur une machine en groupe de travail, c'est votre seul moyen d'accès ; utilisez l'option pour machines non jointes au domaine.
• Une stratégie d'audit ignorée. Les paramètres d'audit avancé ne l'emportent sur les catégories héritées que lorsque Audit: Force audit policy subcategory settings to override audit policy category settings est activé, ce que fait le référentiel Microsoft. Vérifiez-le si l'audit semble incorrect (voir stratégie d'audit et Sysmon).

Liste de contrôle

• SCT, Policy Analyzer, LGPO et paquets de référentiel à jour téléchargés
• Ensembles .PolicyRules pour le référentiel, les GPO actuelles et le référentiel précédent, dans le contrôle de source
• Conflits entre GPO actuelles et référentiel résolus ou documentés
• État effectif de machines témoins comparé au référentiel
• Référentiel testé localement avec LGPO sur une machine de laboratoire avant le déploiement par GPO
• Serveurs autonomes configurés avec l'option de référentiel pour machines non jointes au domaine
• Stratégie locale des hôtes à usage spécifique exportée et versionnée
• Nouvelles publications de référentiel comparées à la version précédente

Policy Analyzer et LGPO rendent les référentiels testables et démontrables. Pour le versant Intune du même problème, voir référentiels de sécurité Intune, et parcourez l'ensemble du domaine référentiels de sécurité.