Mode opératoire — Les stratégies de groupe (GPO) en PowerShell, et la preuve de leur effet

Document autonome. Partie théorique, puis mise en œuvre telle qu’elle a été réalisée et vérifiée le 05/11/2026 sur le contrôleur de domaine AD-Core-01 (10.0.30.10, Windows Server en Server Core, domaine sio.internal) et sur le poste poste-win11 (10.0.40.10, Windows 11 joint au domaine), tâche 6.20 du suivi (SUIVI-TP.md). Tout se fait en PowerShell, par SSH : ni console graphique sur le contrôleur (Server Core n’en a pas), ni session graphique sur le poste (trop lourde pour l’hôte du lab). Prérequis : l’annuaire et son arborescence (MO-9-Comptes-Active-Directory.md), le poste joint au domaine et rangé dans OU=Ordinateurs.

Dernière mise à jour : 05/11/2026 État au 12/11/2026 : 6 GPO, dont 4 liées à OU=Ordinateurs : les 2 de ce MO, plus GPO-Ordi-Poste-Pret (script de démarrage qui installe les agents) et GPO-Ordi-Securisation (LAPS avec le compte géré admin-laps, pare-feu 9182/22/3389, audit, bureau à distance avec NLA), décrites à l’étape 74 de la documentation (schéma de l’AD étendu pour LAPS le 11/11). Pièges : H-98 et H-99.

Sommaire

1 · Ce qu’est une GPO

Une GPO (Group Policy Object, « objet de stratégie de groupe ») est un paquet de réglages Windows rangé dans l’annuaire Active Directory. On l’écrit une fois, sur le contrôleur de domaine ; chaque machine ou utilisateur concerné la récupère et l’applique tout seul, sans qu’un administrateur passe sur le poste.

Une GPO a deux moitiés :

Principe à retenir — Une GPO ne sert pas à « configurer un poste » : elle sert à décrire l’état voulu d’un ensemble de postes. Le contrôleur de domaine dit ce qui doit être ; chaque poste se met en conformité.

Sur le disque, une GPO est faite de deux morceaux : un objet dans l’annuaire (son nom, ses liens, son numéro de version) et un dossier dans SYSVOL (le partage que les postes lisent : réglages de registre, règles de pare-feu). Les commandes de ce MO manipulent les deux à la fois.

2 · Les trois règles qui décident si une GPO agit

1. Une GPO n’agit que là où elle est liée. Créée et remplie, mais pas liée, elle ne touche aucune machine. On la lie à une unité d’organisation (OU) : elle s’applique alors à tout ce qui est rangé dans cette OU et dans ses sous-OU.

2. On ne peut pas lier une GPO à un conteneur. CN=Users et CN=Computers, où Windows range les objets par défaut, sont des conteneurs, pas des OU : aucune GPO ne peut s’y lier. C’est pourquoi le lab redirige les emplacements par défaut vers OU=Utilisateurs et OU=Ordinateurs (redirusr, redircmp, MO-9 §10).

3. Les GPO s’empilent dans un ordre fixe : stratégie locale du poste, puis site, puis domaine, puis OU (de la plus haute à la plus basse). La dernière appliquée gagne en cas de conflit. Ainsi, une GPO liée à OU=Ordinateurs l’emporte sur la Default Domain Policy, liée au domaine.

Ne jamais modifier les deux GPO par défaut (Default Domain Policy, Default Domain Controllers Policy). La première porte la politique de mots de passe du domaine, la seconde les droits des contrôleurs. On crée ses propres GPO, une par sujet : en cas de problème, on désactive la sienne sans toucher au domaine.

Arborescence du lab au 05/11/2026 :

sio.internal                      <- Default Domain Policy (héritée par tout le domaine)
├── OU=Domain Controllers         <- AD-Core-01 (pas concerné par nos GPO)
└── OU=SIO
    ├── OU=Ordinateurs            <- POSTE-WIN11   ← GPO-Ordi-Banniere-Connexion, GPO-Ordi-Pare-feu-Ping,
    │                                              GPO-Ordi-Poste-Pret, GPO-Ordi-Securisation (phase 21, 11/11)
    │   └── OU=Postes-test        <- vide (OU de mise au point des GPO, hérite des 4)
    ├── OU=Utilisateurs           <- Direction, Administratif, Technique
    └── OU=Groupes

Convention de nommage retenue : GPO-<Ordi|Util>-<Sujet>. Le premier mot dit quelle moitié est utilisée, donc à quelle OU la lier.

3 · Les commandes PowerShell, et le contexte du lab

Le module GroupPolicy est installé sur le contrôleur de domaine avec le rôle AD. Il n’existe pas sur le poste (sauf à installer les outils RSAT de gestion des stratégies) : les commandes de création se lancent donc sur le contrôleur, les vérifications sur le poste.

Deux sessions SSH, une par machine, dans deux fenêtres séparées :

ssh sio.internal\administrateur@10.0.30.10

ssh sio.internal\administrateur@10.0.40.10

Piège pratique : l’invite est la même sur les deux machines (PS C:\Users\administrateur>, même compte du domaine). Le 05/11, Get-GPO lancé par erreur sur le poste a répondu « Le terme Get-GPO n’est pas reconnu ». Réflexe : taper hostname avant chaque bloc de commandes.

Les variables meurent avec la session. Les commandes utilisent $g pour le nom de la GPO : si la fenêtre a été fermée, $g est vide, et la commande suivante échoue ou vise rien. Redéfinir la variable avant de reprendre.

4 · GPO 1 — Une bannière d’avertissement avant l’ouverture de session

Contexte — Un poste de l’entreprise doit prévenir, avant la connexion, que l’accès est réservé et que les connexions sont journalisées. C’est une mesure de sécurité classique : elle informe l’utilisateur (loyauté envers les salariés) et elle prive un intrus de l’excuse « je ne savais pas ».

Objectif — Une GPO de la moitié ordinateur, liée à OU=Ordinateurs, qui remplit les deux valeurs de registre lues par Windows à l’écran de connexion.

Windows lit la bannière dans la clé HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System :

4.1 État avant (contrôleur)

Get-GPO -All | Select-Object DisplayName, CreationTime

Get-GPInheritance -Target "OU=Ordinateurs,OU=SIO,DC=sio,DC=internal"

Deux GPO seulement (les deux par défaut) ; GpoLinks : {} (rien de lié à l’OU), InheritedGpoLinks : {Default Domain Policy} (héritée du domaine).

173-gpo-etat-avant.png

4.2 Créer et régler la GPO (contrôleur)

$g = "GPO-Ordi-Banniere-Connexion"

New-GPO -Name $g -Comment "Banniere d'avertissement avant ouverture de session (TP 6.20)"

GpoStatus : AllSettingsEnabled, ComputerVersion : Version AD : 0, Version SysVol : 0 (vide).

Set-GPRegistryValue -Name $g -Key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -ValueName "LegalNoticeCaption" -Type String -Value "Acces reserve - Lab SIO"

Set-GPRegistryValue -Name $g -Key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -ValueName "LegalNoticeText" -Type String -Value "Ce poste appartient au lab SIO. Acces reserve aux personnes autorisees. Les connexions sont journalisees et analysees."

ComputerVersion passe à 2 : chaque modification augmente ce compteur, et c’est lui qui dit aux postes que la GPO a changé. La moitié utilisateur reste à 0.

Pas d’accents dans les valeurs tapées à travers SSH : ils peuvent arriver abîmés (« accès »). Pour un texte accentué, préparer un script .ps1 enregistré en UTF-8 avec BOM sur le contrôleur, ou passer par la console.

Vérification du contenu :

Get-GPRegistryValue -Name $g -Key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"

Deux blocs, LegalNoticeCaption et LegalNoticeText, chacun PolicyState : Set avec son texte.

174-gpo-banniere-creee.png · 175-gpo-banniere-reglage.png · 176-gpo-banniere-contenu.png

4.3 Lier la GPO (contrôleur)

New-GPLink -Name $g -Target "OU=Ordinateurs,OU=SIO,DC=sio,DC=internal" -LinkEnabled Yes

Enabled : True, Enforced : False (une sous-OU pourrait la bloquer : réglage normal), Order : 1.

177-gpo-banniere-liee.png

4.4 Récupérer et prouver (poste)

hostname

Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System | Select-Object LegalNoticeCaption, LegalNoticeText

Avant : colonnes vides. Windows crée ces deux valeurs vides par défaut : la GPO ne les crée pas, elle les remplit.

gpupdate /force

« La mise à jour de la stratégie d’ordinateur s’est terminée sans erreur », idem pour l’utilisateur.

Relancer la commande Get-ItemProperty ci-dessus. Après : Acces reserve - Lab SIO et le texte.

178-gpo-banniere-poste-avant-apres.png

gpresult /r /scope computer

Section « Objets Stratégie de groupe appliqués » : GPO-Ordi-Banniere-Connexion et Default Domain Policy ; Stratégie de groupe appliquée depuis : AD-Core-01.sio.internal ; le poste est bien CN=POSTE-WIN11,OU=Ordinateurs,….

179-gpo-banniere-gpresult.png

Validation — Le registre du poste contient la bannière après gpupdate et pas avant, et gpresult cite la GPO parmi les stratégies appliquées par AD-Core-01. Le réglage vient de l’annuaire, pas d’une modification locale. Effet visible à la prochaine ouverture de session dans la console Proxmox du poste (session déconnectée, puis Ctrl+Alt+Suppr envoyé par le menu de la console noVNC, pas par le clavier du PC) : une fenêtre « Acces reserve - Lab SIO » à valider avant la saisie du mot de passe (vue le 05/11).

185-gpo-banniere-ecran.png

5 · GPO 2 — La réponse au ping, posée par le pare-feu de la GPO

Contexte — Le pare-feu de Windows refuse par défaut le ping venant d’un autre réseau. Sur poste-win11, la règle avait été activée à la main (incident E-04) : un poste neuf ne l’aurait pas. De plus, cette règle locale ne couvrait que les profils Privé et Public, alors que le poste joint au domaine est en profil Domaine (H-82).

Objectif — Une règle de pare-feu écrite dans une GPO, plus stricte que la règle Windows (ping accepté seulement depuis les réseaux du lab), active dans les profils Domaine et Privé ; et la preuve que le ping passe grâce à elle seule.

5.1 Créer la GPO et y écrire la règle (contrôleur)

$g2 = "GPO-Ordi-Pare-feu-Ping"

New-GPO -Name $g2 -Comment "Autorise le ping entrant depuis les reseaux du lab (TP 6.20)"

La règle se crée avec la même commande qu’une règle locale. Seul le paramètre -PolicyStore change : il dit « écris dans cette GPO, pas sur cette machine ».

New-NetFirewallRule -PolicyStore "sio.internal\$g2" -DisplayName "Lab - Ping entrant (ICMPv4 echo)" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.0.0.0/16 -Profile Domain,Private -Action Allow

Enabled : True, Action : Allow, PolicyStoreSourceType : GroupPolicy (la règle est dans la GPO), et EnforcementStatus : NotApplicable : normal, une règle rangée dans une GPO n’agit sur aucune machine tant qu’un poste ne l’a pas récupérée. Le contrôleur lui-même ne la reçoit pas : il n’est pas dans OU=Ordinateurs.

Get-NetFirewallRule -PolicyStore "sio.internal\$g2" | Select-Object DisplayName, Enabled, Direction, Action

Une ligne : Lab - Ping entrant (ICMPv4 echo) True Inbound Allow.

New-GPLink -Name $g2 -Target "OU=Ordinateurs,OU=SIO,DC=sio,DC=internal" -LinkEnabled Yes

Enabled : True, Order : 2.

180-gpo-ping-creee-regle.png · 181-gpo-ping-contenu-liee.png

5.2 Récupérer la GPO (poste)

gpupdate /force

Get-NetFirewallRule -PolicyStore RSOP | Select-Object DisplayName, Enabled, Direction, Action

Lab - Ping entrant (ICMPv4 echo) True Inbound Allow. RSOP (Resultant Set of Policy) = l’ensemble des règles que les GPO ont posées sur ce poste.

5.3 Isoler la GPO : retirer les règles locales qui font la même chose (poste)

Tant qu’une règle locale autorise aussi le ping, un ping réussi ne prouve rien : on ne sait pas laquelle des deux le laisse passer. On liste donc toutes les règles actives qui acceptent la demande d’écho. ActiveStore = ce que le pare-feu applique en ce moment, règles locales et règles de GPO mélangées :

Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Direction Inbound | Where-Object { ($_ | Get-NetFirewallPortFilter).IcmpType -eq 8 } | Select-Object DisplayName, Profile, PolicyStoreSourceType

Le 05/11, quatre règles sortaient : la nôtre (GroupPolicy) et trois règles locales du groupe Partage de fichiers et d’imprimantes :

On les désactive (on ne les supprime pas : ce sont des règles fournies par Windows) :

Disable-NetFirewallRule -Name FPS-ICMP4-ERQ-In, FPS-ICMP4-ERQ-In-V2, FPS-ICMP4-ERQ-In-NoScope

Puis on relance la commande ActiveStore ci-dessus. Une seule ligne : Lab - Ping entrant (ICMPv4 echo) Domain, Private GroupPolicy.

182-gpo-ping-poste-rsop-regle-manuelle-off.png · 183-gpo-ping-seule-regle-active.png

5.4 Le test (depuis une autre zone du lab)

Depuis srv-docker (zone ADM, 10.0.30.0/24) :

ping -c3 -W2 10.0.40.10

3 packets transmitted, 3 received, 0% packet loss (05/11 à 11:36:40).

184-gpo-ping-test-srv-docker.png

Validation — Une seule règle d’écho est active sur le poste, elle vient de la GPO, et le ping passe. La réponse au ping est donnée par l’annuaire : un poste neuf rangé dans OU=Ordinateurs l’aura sans intervention.

5.5 La contre-épreuve : prouver que la règle filtre sur l’adresse

Le test du §5.4 prouve que la règle ouvre. Il reste à prouver qu’elle refuse ce qu’elle n’autorise pas. Dans le lab, aucune machine hors de 10.0.0.0/16 ne peut joindre le poste : on garde donc la même source et on rétrécit la règle le temps du test. Seule la plage change entre les deux essais.

Sur le contrôleur :

Set-NetFirewallRule -PolicyStore "sio.internal\GPO-Ordi-Pare-feu-Ping" -DisplayName "Lab - Ping entrant (ICMPv4 echo)" -RemoteAddress 10.0.40.0/24

Sur le poste : gpupdate /force, puis la commande ActiveStore du §5.3. Une seule règle d’écho active, celle de la GPO, avec remote=10.0.40.0/255.255.255.0 (sinon, désactiver les règles locales comme au §5.3).

Depuis srv-docker (10.0.30.12, hors de 10.0.40.0/24) : ping -c3 -W2 10.0.40.10. 100 % de perte.

Remise en état : la même commande Set-NetFirewallRule avec -RemoteAddress 10.0.0.0/16, gpupdate /force sur le poste, puis le ping. 0 % de perte.

Résultat du 05/11 : refusé à 12:01:41, rétabli à 12:02:23. 186-gpo-ping-contre-epreuve.png

Si le ping passe encore avec la plage rétrécie : une autre règle l’autorise. Relancer la commande ActiveStore. Pour voir l’adresse source réelle reçue par le poste, capturer les paquets avec l’outil intégré à Windows : pktmon filter add PING -t ICMP, pktmon start --capture --comp nics -f C:\Windows\Temp\ping.etl, le ping, puis pktmon stop et pktmon etl2txt C:\Windows\Temp\ping.etl (et pktmon filter remove pour finir).

6 · Prouver qu’une GPO agit : la méthode générale

Principe à retenir — Un effet constaté ne prouve pas qu’une GPO fonctionne : il faut d’abord écarter les réglages locaux qui produiraient le même effet. Le 05/11, sans l’étape 5, on aurait attribué à la GPO un ping que deux règles locales oubliées laissaient déjà passer.

Les GPO de la moitié utilisateur ne s’appliquent qu’à l’ouverture d’une vraie session de l’utilisateur concerné. En SSH avec un compte administrateur, gpresult /scope user décrit la session de l’administrateur, pas celle d’un utilisateur de OU=Utilisateurs : la preuve demande une session de l’utilisateur visé À VÉRIFIER (pas de GPO utilisateur posée dans le lab au 05/11).

7 · Modifier, désactiver, supprimer, revenir en arrière

Retour arrière propre au lab — à ne lancer que si la GPO de ping est retirée (sinon les règles locales reprennent la main et le ping n’est plus limité au lab) — rétablir les règles locales sur le poste :

Enable-NetFirewallRule -Name FPS-ICMP4-ERQ-In, FPS-ICMP4-ERQ-In-V2, FPS-ICMP4-ERQ-In-NoScope

8 · Pièges et checklist

 La GPO a un nom qui dit sa moitié et son sujet (GPO-Ordi-… / GPO-Util-…)
 Les GPO par défaut ne sont pas modifiées
 Contenu relu sur le contrôleur avant de lier (Get-GPRegistryValue / Get-NetFirewallRule -PolicyStore)
 Liée à l'OU où se trouvent les objets visés (Get-GPInheritance ; DistinguishedName de l'objet)
 hostname vérifié avant chaque bloc de commandes
 Poste : état avant relevé, gpupdate /force, état après
 gpresult cite la GPO dans les stratégies appliquées
 Réglages locaux équivalents retirés avant le test final
 Contre-épreuve : le refus attendu est obtenu quand la règle ne couvre plus la source
 Retour arrière écrit (Set-GPLink -LinkEnabled No + réglages locaux à rétablir)
 Captures avant / après rangées

La règle à retenir en une phrase : une GPO n’agit que là où elle est liée, et on ne la déclare efficace qu’après avoir vu le poste l’appliquer et écarté tout réglage local qui ferait la même chose.