Paramètres de sécurité GPO Active Directory : quatre contrôles

Que sont les paramètres de sécurité GPO Active Directory ?

Les paramètres de sécurité GPO Active Directory déterminent comment les clients Windows résolvent les noms locaux, accordent leur confiance aux métadonnées de mise à jour, protègent LSASS et authentifient l’accès aux partages de stratégies. Quatre paramètres méritent une revue ciblée : désactiver LLMNR, utiliser HTTPS pour les métadonnées WSUS, activer la protection LSA et exiger l’authentification mutuelle ainsi que l’intégrité pour SYSVOL et NETLOGON.

Chacun répond à un prérequis d’attaque différent. Une connexion de mise à jour sécurisée ne protège pas la mémoire de LSASS ; désactiver LLMNR ne désactive pas la résolution de noms NetBIOS. Examinez la valeur de stratégie, les ordinateurs qui la reçoivent et la protection réellement utilisée avant de clôturer un constat.

Notre guide des mauvaises configurations GPO examine les permissions de modification déléguées, les liens de stratégies, LAPS et la gouvernance des stratégies de mot de passe. Ce parcours couvre quatre paramètres précis qui peuvent rester dangereux même lorsque les permissions d’administration d’une GPO sont correctes.

Fonctionnement : quatre stratégies et leurs valeurs de registre

Utilisez les paramètres suivants comme cibles de revue. Les valeurs attendues décrivent une configuration souhaitée, et non les résultats d’un audit de votre environnement.

1. Désactiver LLMNR ; traiter NBT-NS séparément

Chemin de stratégie : Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution.

Clé de registre : HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient ; valeur : EnableMulticast, REG_DWORD 0. La formulation négative de la stratégie compte : Activé désactive LLMNR. Microsoft documente la correspondance des stratégies du client DNS ; sa référence de baseline Windows Server précise la valeur zéro.

LLMNR assure la résolution de noms locaux lorsque la résolution DNS conventionnelle est indisponible. Un attaquant capable d’influencer cet échange local peut rediriger un client vers une destination qu’il contrôle et provoquer une authentification, comme le décrit la fiche MITRE ATT&CK sur l’empoisonnement de la résolution de noms. Les réponses NTLMv2 capturées ne sont pas des mots de passe en clair : Microsoft décrit NTLM comme un protocole de défi-réponse. Le relais d’authentification dépend également des protections du service de destination.

NBT-NS constitue une exposition distincte. Microsoft documente Win32_NetworkAdapterConfiguration.SetTcpipNetbios avec TcpipNetbiosOptions=2 pour désactiver NetBIOS sur TCP/IP pour un adaptateur. Traitez cette méthode au niveau de l’adaptateur comme une décision de déploiement distincte, avec ses propres vérifications de compatibilité. La stratégie LLMNR et le contrôle EtcSec correspondant n’établissent pas la couverture de NetBIOS.

2. Protéger les métadonnées WSUS avec HTTPS

Chemin de stratégie : Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location. Les modèles de stratégies Windows 10/11 la placent sous Manage updates offered from Windows Server Update Service.

Clé de registre : HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate ; valeurs : WUServer et WUStatusServer, toutes deux REG_SZ. Configurez l’URL HTTPS du serveur déployé dans les deux champs. La valeur associée HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer est REG_DWORD 1 pour l’utilisation de WSUS. Ces correspondances sont documentées dans les paramètres Windows Update.

La procédure de configuration WSUS de Microsoft distingue les métadonnées en HTTPS de la distribution des fichiers en HTTP. Un attaquant situé sur le trajet du trafic peut altérer les informations de mise à jour non protégées. Évaluez les clients qui utilisent réellement ce serveur et le trajet pouvant être intercepté ; ne déduisez pas la compromission de tous les ordinateurs joints au domaine à partir d’une seule URL.

3. Activer la protection LSA avec une valeur RunAsPPL prise en charge

Pour Windows 11 22H2 et les versions ultérieures, le chemin de modèle d’administration documenté par Microsoft est Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process. L’alternative documentée par les préférences de stratégie de groupe est Computer Configuration > Preferences > Windows Settings > Registry.

Clé de registre : HKLM\SYSTEM\CurrentControlSet\Control\Lsa ; valeur : RunAsPPL, REG_DWORD. 1 sélectionne la protection avec verrouillage UEFI lorsque pris en charge ; Microsoft limite l’application de 2, sans ce verrouillage, à Windows 11 22H2 et aux versions ultérieures. Sur les appareils x86/x64 sans prise en charge UEFI ou avec Secure Boot désactivé, la configuration repose sur le registre plutôt que sur un verrouillage du firmware. Redémarrez après la configuration. Suivez la procédure Microsoft de protection LSA.

Protected Process Light limite les lectures de mémoire et l’injection de code par des processus non protégés. L’absence de protection peut faciliter le vol d’identifiants après qu’un attaquant a obtenu l’accès nécessaire. Une valeur de registre seule ne démontre pas la protection du processus en cours d’exécution. Certains clients modernes activent automatiquement la protection LSA ; l’absence d’une valeur GPO collectée nécessite une investigation, et non l’affirmation catégorique que LSASS n’est pas protégé.

4. Exiger l’authentification mutuelle et l’intégrité pour les partages de stratégies

Chemin de stratégie : Computer Configuration > Administrative Templates > Network > Network Provider > Hardened UNC Paths.

Clé de registre : HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths. Définissez les deux noms de valeurs REG_SZ, \\*\SYSVOL et \\*\NETLOGON, sur RequireMutualAuthentication=1,RequireIntegrity=1. La correspondance des stratégies Connectivity établit l’emplacement de la stratégie et la clé de registre ; la référence de baseline précise les attributs requis.

L’authentification mutuelle exige la validation de l’identité du serveur par Kerberos ; l’intégrité exige la signature SMB. Microsoft décrit le renforcement UNC et les défenses contre l’interception, y compris le renforcement par défaut de SYSVOL et NETLOGON à partir de Windows 10 et Windows Server 2016.

Notre guide cPassword dans SYSVOL explique pourquoi les anciens secrets GPP nécessitent un nettoyage et une rotation des identifiants, et recommande déjà le renforcement UNC. Ici, l’accent porte sur les motifs de partage précis et les exigences de connexion. Protéger le transit ne supprime pas les secrets stockés et ne corrige pas les permissions d’écriture excessives.

Chaîne d’attaque : des prérequis distincts, des contrôles distincts

Il s’agit de quatre chemins indépendants, et non de quatre étapes obligatoires d’une seule exploitation. Utilisez cette distinction pour délimiter une investigation :

Un constat de configuration justifie des travaux de renforcement. Il n’établit pas qu’un attaquant a capturé des identifiants, altéré une mise à jour, extrait la mémoire de LSASS ou modifié une stratégie en transit. Rattachez toute conclusion d’incident à une télémétrie indépendante.

Détection : mesurer l’ordinateur cible

Commencez sur une cible Windows dans chaque périmètre de stratégie pertinent. La référence gpresult de Microsoft documente la sortie RSoP au niveau ordinateur :

gpresult /scope computer /r

Le résumé aide à identifier les GPO appliquées. Utilisez une sortie RSoP détaillée pour examiner les paramètres en conflit, puis comparez-la aux valeurs locales et aux preuves d’exécution. Répétez les contrôles pour chaque cible dont vous examinez le périmètre de stratégie.

Les commandes suivantes appliquent la syntaxe reg query documentée par Microsoft aux clés étayées par Learn ci-dessus. Exécutez chacune séparément.

Mesurer la configuration LLMNR

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast

La valeur attendue est REG_DWORD 0. Si la valeur est absente ou différente, rapprochez-la du résultat de stratégie de la cible avant de conclure que le déploiement a réussi. Examinez les destinations inattendues de résolution de noms locaux comme un signal d’investigation. La référence des alertes Defender for Identity de Microsoft reconnaît la famille de techniques d’empoisonnement LLMNR/NBT-NS et de relais SMB ; elle n’établit pas un Event ID Windows universel pour ce contrôle.

Mesurer la configuration WSUS

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

Examinez ensemble WUServer, WUStatusServer et l’entrée AU\UseWUServer. Comparez les URL au FQDN et au port HTTPS attendus, validez la confiance dans le certificat et confirmez la réussite des recherches de mises à jour par les clients. Une chaîne HTTPS seule ne valide ni IIS, ni la gestion des certificats, ni l’utilisation réelle par les clients. Les sources utilisées ici n’établissent aucun Event ID spécifique d’attaque WSUS.

Mesurer la configuration et le démarrage LSA

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL

Pour confirmer l’état à l’exécution, examinez System / WinInit / Event 12 après redémarrage. Cet événement enregistre le démarrage protégé de LSASS. La référence wevtutil documente la recherche d’événements ; cet exemple sélectionne les enregistrements Event 12 à examiner :

wevtutil qe System /q:"*[System[(EventID=12)]]" /rd:true /f:text /c:10

Confirmez que le fournisseur est WinInit et que le message concerne le démarrage protégé de LSASS. Le filtre sélectionne par ID, donc des fournisseurs sans rapport peuvent apparaître. Dans CodeIntegrity/Operational, l’événement d’audit 3065 concerne les exigences de sections partagées et 3066 les exigences de niveau de signature Microsoft ; le chargement de l’image reste autorisé en mode audit. Sous protection, 3033 identifie les échecs de niveau de signature et 3063 les échecs de sections partagées. Ces événements ne prouvent pas une extraction réussie d’identifiants. L’absence de preuve de démarrage conservée ne prouve pas, à elle seule, que la protection est désactivée.

Mesurer la configuration UNC

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths"

Examinez les deux motifs de partage et les attributs requis. Lorsque les entrées sont absentes, tenez compte des valeurs par défaut du système d’exploitation avant de classer l’exposition. Validez l’accès aux véritables destinations SYSVOL et NETLOGON ainsi que leurs garanties d’authentification et d’intégrité. Aucun Event ID spécifique d’usurpation UNC n’est établi ici.

Remédiation : déployer et vérifier chaque contrôle (Remediation)

Étape 1 : désactiver LLMNR dans un périmètre pilote

Activez la stratégie du client DNS décrite ci-dessus. Réexécutez la requête de registre LLMNR et rapprochez le résultat des stratégies appliquées à l’ordinateur. Vérifiez que les applications utilisant des noms locaux continuent de résoudre les destinations attendues. Si NetBIOS reste nécessaire, consignez cette dépendance séparément ; s’il peut être désactivé, gérez la méthode documentée au niveau de l’adaptateur séparément du paramètre du client DNS.

Étape 2 : configurer TLS sur WSUS avant de changer les URL clients

Configurez le certificat serveur, les liaisons IIS et les racines virtuelles nécessitant TLS selon la procédure WSUS de Microsoft. Depuis une invite de commandes élevée dans C:\Program Files\Update Services\Tools, la commande documentée est :

wsusutil configuressl <certificate-name>

Remplacez le paramètre fictif par le nom DNS du serveur WSUS. Exigez TLS pour les services de métadonnées documentés, dont ClientWebService ; ne l’exigez pas pour tout le site web WSUS. La distribution des fichiers utilise toujours HTTP, avec validation des signatures et des hachages. Mettez à jour les deux URL de stratégie des clients vers le point de terminaison HTTPS déployé ; https://wsus.contoso.com:8531 est l’exemple de Microsoft, et non un serveur découvert. Vérifiez la confiance dans le certificat et la recherche de mises à jour avant un déploiement large.

Étape 3 : tester la compatibilité LSA, activer la protection et redémarrer

Utilisez l’audit de compatibilité de la procédure LSA avant l’application de la protection. Résolvez les incompatibilités des plug-ins et des pilotes, sélectionnez l’option RunAsPPL prise en charge, redémarrez et vérifiez le démarrage protégé. Les événements d’audit ne sont pas générés lorsque Smart App Control est activé ou qu’un débogueur de noyau est attaché et activé ; le silence ne constitue donc pas une validation automatique de compatibilité. Examinez les implications du verrouillage UEFI avant de le choisir : modifier le registre seul ne supprime pas la variable du firmware. La protection LSA et Credential Guard sont des contrôles complémentaires.

Étape 4 : exiger les deux attributs UNC sur les deux partages

Configurez explicitement SYSVOL et NETLOGON dans la stratégie Hardened UNC Paths. Testez la récupération des stratégies depuis chaque périmètre cible et examinez les échecs d’authentification ou d’accès avant d’élargir le déploiement. Ajoutez RequirePrivacy uniquement après avoir vérifié la compatibilité du chiffrement ; les points de terminaison non pris en charge peuvent devenir inaccessibles. Examinez les permissions d’écriture et les secrets réutilisables dans des tâches distinctes, même lorsque les exigences de transport sont satisfaites.

Conservez une trace concise pour chaque déploiement : système d’exploitation et périmètre cibles, GPO appliquées, sortie du registre avant/après, preuves pertinentes d’exécution ou de connexion, et toute dépendance non résolue. Réexécutez les mêmes mesures après les modifications de stratégies afin qu’un relecteur ultérieur puisse distinguer un paramètre modifié d’une nouvelle interprétation des valeurs par défaut.

Comment EtcSec détecte ce problème

Les quatre implémentations Detect() d’etc-collector examinées pour cet article évaluent les données de registre GPO collectées :

Les fonctions auxiliaires du registre recherchent la stratégie par défaut des contrôleurs de domaine, puis la stratégie par défaut du domaine, puis une autre GPO disponible. Le code agrège les valeurs GPO et ne prouve pas la configuration effective de chaque poste de travail. Il ne calcule pas, pour chaque ordinateur, la priorité des liens, le filtrage et l’héritage. Les GPO contradictoires ou hors périmètre nécessitent donc une confirmation sur la cible.

La fonction auxiliaire UNC recherche les deux chaînes d’attributs requises ; ce n’est pas un analyseur de stratégie effective. Un WUServer absent ne déclenche pas le contrôle HTTP, mais cette absence ne valide pas la stratégie de mise à jour. De même, l’absence d’entrées PPL ou UNC peut nécessiter l’examen des valeurs par défaut modernes. Utilisez chaque constat pour ouvrir une tâche de vérification ciblée, joindre les preuves de la cible et ne la clôturer que lorsque la protection attendue est démontrée pour le périmètre concerné.