GPO Active Directory : durcissement, abus et contrôle

GPO Active Directory : durcissement, abus et contrôle

Une GPO (Group Policy Object, objet de stratégie de groupe) est une circulaire qui s’applique d’office à tous les services de son périmètre, qu’ils l’aient lue ou non. C’est le principal levier de durcissement d’un parc Windows et, pour la même raison, un point de concentration de risque majeur. Qui dispose du droit d’écriture sur une GPO applique sa configuration à tout ce qu’elle touche : la page part de ce fait.

Explication de la marmotte

Dans un lycée, la direction affiche une note de service que tout un bâtiment doit suivre, sans discussion. C’est pratique pour imposer partout la même consigne d’un coup. Le revers : celui qui tient le classeur des notes officielles décide, en une feuille, de ce que font toutes les classes concernées.

→ Lire l’explication complète de la marmotte

Contenu, stockage et liaison d’une GPO

Une GPO porte deux moitiés indépendantes : la configuration ordinateur, appliquée au démarrage puis périodiquement dans le contexte du compte machine, et la configuration utilisateur, appliquée à l’ouverture de session. Chacune regroupe plusieurs familles : modèles d’administration (réglages de registre décrits par des fichiers ADMX (modèles d’administration au format XML), centralisables dans le magasin central de SYSVOL (le partage répliqué des contrôleurs de domaine)), paramètres de sécurité (stratégie de mots de passe, attribution des droits utilisateur, options de signature SMB (Server Message Block), groupes restreints, audit, pare-feu), scripts de démarrage et d’ouverture de session, et préférences, dites GPP (Group Policy Preferences), apparues avec Windows Server 2008 : fichiers, registre, tâches planifiées, comptes locaux, lecteurs mappés.

Le point structurant pour la sécurité : une GPO n’est pas un fichier unique. Elle se dédouble. Le conteneur de stratégie de groupe (GPC) vit dans l’annuaire, sous CN=Policies,CN=System du domaine, et porte les métadonnées plus le numéro de version. Le modèle de stratégie de groupe (GPT) vit dans SYSVOL, partage répliqué sur tous les contrôleurs de domaine, et contient les fichiers concrets : registre, scripts, modèles. SYSVOL est accessible en lecture par tout utilisateur authentifié du domaine. Autrement dit, tout ce qu’une GPO embarque de sensible est lisible par n’importe quel compte du domaine, ce qui a des conséquences directes traitées plus bas.

Ce schéma montre pourquoi une GPO peut se désynchroniser : annuaire et fichiers empruntent deux canaux de réplication différents, avec deux rythmes. Une version qui diverge entre GPC et GPT donne une GPO qui s’applique de travers, à moitié, ou pas du tout.

LSDOU, héritage et les leviers qui cassent l’ordre

Une GPO ne fait rien tant qu’elle n’est pas liée à un conteneur : un site, le domaine, ou une unité d’organisation (OU). L’ordre d’application suit LSDOU (Local, Site, Domaine, OU) : Local d’abord (stratégie locale de la machine), puis Site, puis Domaine, puis OU du plus haut au plus bas. Dernier appliqué gagne : une GPO liée à l’OU la plus profonde écrase un paramètre contradictoire défini plus haut. À un même niveau, l’ordre de liaison tranche, du plus faible au plus fort.

Trois leviers modifient cette mécanique, et chacun est un piège quand on l’oublie. Le blocage d’héritage sur une OU coupe l’arrivée des GPO des niveaux supérieurs : commode pour isoler une OU serveurs, désastreux quand il bloque au passage la base de durcissement du domaine. L’application forcée (enforced) sur une liaison inverse la logique : la GPO forcée gagne, ignore le dernier appliqué, et traverse même les blocages d’héritage. Une GPO de durcissement sérieuse se lie en forcée au plus haut niveau pertinent, précisément pour qu’aucune OU ne puisse s’en soustraire. Le filtrage enfin détermine qui subit réellement la GPO.

Le filtrage de sécurité repose sur les permissions de la GPO elle-même : un objet doit avoir Lecture et le droit étendu « Appliquer la stratégie de groupe » pour que la GPO le vise. Retirer « Utilisateurs authentifiés » du filtrage et le remplacer par un groupe ciblé est une pratique de durcissement correcte, à une condition qu’on oublie régulièrement : les comptes machine doivent conserver la lecture, sinon l’ordinateur ne peut plus lire la GPO du tout. Le filtrage WMI (Windows Management Instrumentation) ajoute une condition évaluée à chaud sur la machine (version d’OS, modèle, espace disque). Puissant, coûteux : chaque filtre WMI est réévalué à chaque rafraîchissement.

Le rafraîchissement, justement : toutes les 90 minutes environ pour les machines et utilisateurs, avec un décalage aléatoire pour éviter la ruée simultanée, toutes les 5 minutes pour les contrôleurs de domaine. Certains paramètres (attribution de droits, scripts) ne s’appliquent pleinement qu’au redémarrage ou à l’ouverture de session. Une GPO poussée n’est donc pas une GPO appliquée : il y a un délai, et il n’est pas nul.

Les GPO comme outil de durcissement

C’est l’usage pour lequel la mécanique existe, et il est redoutablement efficace parce qu’il ne demande l’accord de personne sur les postes. Les bases de sécurité Microsoft (Security Baselines, distribuées via le Security Compliance Toolkit) fournissent des GPO prêtes à importer qui règlent plusieurs centaines de paramètres cohérents entre eux. Les guides de l’ANSSI (Agence nationale de la sécurité des systèmes d’information) sur Active Directory et le durcissement Windows pointent les paramètres qui comptent vraiment. Importer une base ne dispense pas de la lire : une base appliquée les yeux fermés casse des applications métier qui s’appuyaient justement sur ce qu’elle désactive.

Les cibles de durcissement classiques, toutes pilotables par GPO :

• Pare-feu Windows Defender : règles de profil appliquées de force, trafic entrant restreint, ce qui limite le mouvement latéral SMB et RPC (Remote Procedure Call) poste à poste.
• Désactivation des protocoles hérités : refus de NTLMv1 et de LM via le niveau d’authentification LAN Manager, désactivation du client et du serveur SMBv1. Sur le pourquoi, voir la page NTLM : fonctionnement, vulnérabilités et durcissement.
• Restriction logicielle : AppLocker ou Windows Defender Application Control pour n’autoriser que les binaires signés ou référencés, ce qui coupe l’exécution opportuniste depuis les répertoires inscriptibles.
• LAPS (Local Administrator Password Solution), intégré nativement à Windows depuis les mises à jour d’avril 2023 sous le nom Windows LAPS : un mot de passe d’administrateur local unique et aléatoire par machine, renouvelé automatiquement, stocké dans l’annuaire. Fin des comptes locaux au même mot de passe sur tout le parc, donc fin du Pass-the-Hash qui déroule le réseau entier à partir d’un seul poste compromis.

Le compromis central est là, et il faut le nommer : la GPO troque la confirmation individuelle contre l’application de masse. On gagne un durcissement uniforme, auditable, qui s’impose sans visite physique. On paie une surface d’exécution privilégiée centralisée, un délai d’application non nul, et une fragilité aux erreurs d’étendue (une GPO liée trop haut durcit des serveurs qu’elle devait épargner). Cette logique de réduction d’exposition rejoint le durcissement système par minimisation de surface : moins de protocoles actifs, moins de binaires autorisés, moins de chemins.

Les GPO comme vecteur d’attaque

Retourner le levier est trivial dès qu’on tient le bon droit. Le principe tient en une phrase : le droit d’écriture sur une GPO liée, ou le droit de lier une GPO à une OU, équivaut à l’exécution de code sur toutes les machines concernées, dans le contexte SYSTEM pour la partie ordinateur. Pas besoin d’être administrateur du domaine. Il suffit de contrôler le bon maillon.

La chaîne droit de modification vers tous les postes

Ce schéma est la chaîne à auditer en priorité. Trois maillons alternatifs mènent au même point : écrire dans une GPO déjà liée, lier une GPO contrôlée à une OU, ou écrire directement dans SYSVOL si les permissions du partage sont trop larges. Les délégations excessives en sont la cause quasi unique : un groupe « support N2 » à qui on a donné « contrôle total » sur une OU pour qu’il crée des comptes, et qui hérite au passage du droit de lier des GPO ; un groupe d’édition de GPO dont l’appartenance a dérivé depuis des années. La cartographie de ces droits relève de la même analyse que les chemins d’attaque Active Directory et de la structure, délégations et chemins d’attaque AD.

cpassword : le mot de passe que SYSVOL a trop longtemps gardé

Les préférences de stratégie de groupe permettaient de définir ou modifier un mot de passe de compte local, de lecteur mappé ou de tâche planifiée, stocké dans un fichier XML du GPT. Ce mot de passe était chiffré en AES, mais Microsoft avait publié la clé de déchiffrement dans sa documentation. Résultat : l’attribut cpassword dans un XML de SYSVOL se déchiffre hors ligne, instantanément, par n’importe quel compte du domaine (rappel : SYSVOL est lisible par tous les authentifiés). Le correctif MS14-025, publié en 2014, a retiré la capacité de créer de nouvelles préférences avec mot de passe. Il n’a pas nettoyé les fichiers existants. Des cpassword dormants traînent encore dans SYSVOL d’annuaires jamais audités, et les récupérer est l’un des premiers gestes d’une reconnaissance interne. Un passage de recherche sur l’ensemble de SYSVOL, à comparer avec l’inventaire des comptes locaux, fait partie du strict minimum.

Les rançongiciels adorent les GPO

Le mode de déploiement rêvé d’un rançongiciel sur un parc Windows, c’est précisément la GPO : un seul point d’écriture, une diffusion automatique en SYSTEM à l’échelle d’une OU ou du domaine, aucun agent à installer. Un opérateur qui obtient les droits d’administration du domaine crée fréquemment une GPO (ou en détourne une existante) pour pousser une tâche planifiée immédiate ou un script qui désactive les défenses puis lance la charge sur chaque machine d’un coup. La GPO transforme une compromission d’annuaire en incident à l’échelle du parc, sans étape intermédiaire visible.

Contrôle : revue des droits, cartographie, journalisation et sauvegarde

Le contrôle d’une GPO se joue sur quatre fronts, et aucun ne se suffit à lui-même.

Revue des droits. Énumérer, pour chaque GPO, qui a WriteDACL, WriteOwner, WriteProperty ou GenericAll ; pour chaque OU, qui peut lier une GPO et créer des objets ; sur SYSVOL, qui écrit. Le principe de moindre privilège s’applique durement ici : l’édition de GPO est un pouvoir de niveau administrateur, à réserver à un groupe nommé, restreint, et traité comme un actif de niveau 0.

Cartographie des chemins. Les droits isolés ne disent rien ; ce sont les chaînes qui tuent. Un outil comme BloodHound matérialise les arêtes GenericAll, WriteDacl, GPLink, WriteGPLink et affiche d’un trait le chemin qui mène d’un compte quelconque à l’exécution sur une OU. C’est l’inventaire des chaînes du schéma précédent, à faire tourner régulièrement et après chaque délégation.

Journalisation. Activer l’audit des modifications d’objets GPO dans l’annuaire et des écritures dans SYSVOL. Une création ou une modification de GPO en dehors des fenêtres de changement connues, une liaison nouvelle sur une OU sensible, un script ajouté à une GPO qui n’en avait jamais : autant d’alertes qui méritent une réaction immédiate, pas une revue trimestrielle.

Versions et sauvegarde. La console de gestion (GPMC) sauvegarde les GPO avec leur historique. Sans sauvegarde, une GPO supprimée ou corrompue ne se restaure pas d’un clic, et une modification malveillante ne se compare à aucune référence. Garder une copie hors annuaire des GPO de durcissement, horodatée, permet de détecter une dérive et de rétablir l’état connu.

Exemple : repérer les cpassword résiduels dans SYSVOL

Avant toute autre chose sur un annuaire jamais audité, chercher les cpassword oubliés. Cette commande PowerShell parcourt le partage SYSVOL du domaine et liste les fichiers de préférences qui contiennent encore l’attribut.

# Recherche des cpassword résiduels (post-MS14-025 ne nettoie PAS l'existant)
# \SYSVOL\<domaine>\Policies contient les GPT de toutes les GPO
Get-ChildItem -Path "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies" `
  -Recurse -Include *.xml -ErrorAction SilentlyContinue |
  Select-String -Pattern "cpassword" |
  Select-Object Path, LineNumber
# Chaque résultat = un mot de passe déchiffrable hors ligne par tout compte du domaine

Chaque ligne renvoyée désigne un fichier XML dans SYSVOL exposant un mot de passe récupérable par n’importe quel utilisateur authentifié. La correction n’est pas de changer la clé (elle est publique et figée) mais de supprimer la préférence fautive, de retirer le compte local concerné, et de faire tourner tout mot de passe qui a transité par ce mécanisme.

FAQ

Une GPO liée en « application forcée » traverse-t-elle un blocage d’héritage ?

Oui. L’application forcée (enforced) prime sur le blocage d’héritage et sur la règle du dernier appliqué. C’est exactement pourquoi les bases de durcissement sérieuses se lient en forcée au niveau domaine : aucune OU ne peut alors s’en exonérer par un blocage local.

Retirer « Utilisateurs authentifiés » du filtrage de sécurité suffit-il à masquer une GPO ?

Le filtrage écarte l’application, pas la lecture des fichiers. Le GPT reste dans SYSVOL, lisible par tout compte authentifié quel que soit le filtrage. Aucun secret ne doit transiter par une GPO en comptant sur le filtrage comme protection de confidentialité.

🐝 Ce qui arrive si on s’en passe

Sans stratégie de groupe appliquée, chaque poste ne garde que sa configuration par défaut et sa stratégie locale. Tout administrateur local peut la modifier, et aucune référence commune ne permet de mesurer l’écart. Plusieurs comportements par défaut de Windows restent alors actifs. La résolution de noms LLMNR (Link-Local Multicast Name Resolution) et NetBIOS permet à une machine du même segment de répondre à une requête de nom et de capter une authentification NTLM. La signature SMB n’est pas exigée sur les serveurs membres des versions antérieures à Windows Server 2025, ce qui laisse relayer ces authentifications. La détection en pâtit aussi : par défaut, la création de processus (événement 4688) et sa ligne de commande ne sont pas journalisées. Une exécution malveillante sur un poste ne laisse alors aucune trace exploitable dans le journal Sécurité.

🦫 Explication de la marmotte 🍫

Dans un réseau d’entreprise sous Windows, un serveur central tient l’annuaire de tous les comptes et de toutes les machines. Une stratégie de groupe est un paquet de réglages qu’on range à deux endroits à la fois : une fiche dans l’annuaire, avec un numéro de version, et des fichiers dans un dossier partagé que toutes les machines peuvent lire. On accroche ce paquet à un groupe de machines ou d’utilisateurs. À intervalle régulier, chaque machine va chercher les paquets qui la concernent et applique les réglages toute seule, sans que personne n’ait à passer sur chaque poste. Quand plusieurs paquets se contredisent, c’est celui accroché au plus près de la machine qui l’emporte, sauf si un paquet est marqué « prioritaire ». Ça sert à imposer d’un coup des règles de sécurité partout : interdire les vieux protocoles dangereux, bloquer les programmes non autorisés, donner à chaque poste un mot de passe d’administrateur différent. Le problème, c’est que celui qui obtient le droit de modifier un de ces paquets peut y glisser un programme, et toutes les machines concernées l’exécuteront avec les pleins pouvoirs. Un mot de passe mal rangé dans ces fichiers partagés peut aussi se lire sans effort, car le dossier est ouvert à tous les comptes. Se protéger revient donc à savoir qui a le droit de toucher à quoi, à surveiller chaque modification, et à garder des copies pour revenir en arrière.

À lire aussi

• Registre Windows, GPO et services, fonctionnement et attaquesComment le registre Windows, les GPO et les services s'articulent, où se logent la persistance et l'élévation de privilèges, et ce qu'il faut verrouiller en premier.
• L'administration Active Directory en tiers en une pageTiers 0, 1 et 2 : pourquoi un admin du domaine connecté sur un poste de travail expose tout le domaine, et les cloisons qui l'en empêchent : un compte par tier, poste d'administration dédié, LAPS, Protected Users.
• WannaCry et MS17-010 : fenêtre d'exposition et correctifsWannaCry, EternalBlue et MS17-010 montrent comment les deux mois entre un correctif publié et un correctif déployé deviennent la fenêtre d'exposition d'un parc Windows.
• Configurer Windows Hello for Business sans mot de passeGuide pratique de déploiement de l’authentification sans mot de passe sur Active Directory avec Windows Hello for Business.

Pages voisines

La citent

• WannaCry et MS17-010 : fenêtre d'exposition et correctifs

GPO Active Directory : durcissement, abus et contrôle

Elle cite

• Active Directory délégations et chemins d’attaque
• Comment structurer Active Directory et déléguer sans escalade
• Durcissement Linux et Windows par minimisation de surface
• NTLM : protocole authentification LAN Manager New Technology Microsoft