Dans cet article, je vais vous expliquer comment créer une stratégie de groupe, aussi appelé GPO en respectant quelques pratiques et erreur à éviter dans votre domaine Active Directory.
Avant de commencer, je vous invite à lire ce cours qui va vous aider dans un premier temps à comprendre les paramètres Utilisateurs et Ordinateurs de façon à bien placer vos GPO : Présentation des stratégies de groupe
Sommaire
Les mauvaises pratiques
Commençons tout de suite par ce que je considère comme de mauvaises pratiques en matière de stratégie de groupe.
1. Ne pas anticiper la stratégie de groupe
La première erreur est de ne pas réfléchir en amont à la stratégie de groupe et d’appliquer directement des paramètres sans planification. Commencez par définir précisément ce que vous souhaitez mettre en place. Vérifiez si cela peut être appliqué au niveau utilisateur, ordinateur ou les deux. Analysez si la configuration peut être réalisée via des paramètres de stratégie, une modification du registre ou un script.
Cette première étape peut être testée en local sur une machine via la console gpedit.msc ou dans un environnement de test (Lab).
2. Manque d’organisation des GPO
Trop souvent, il n’existe aucune organisation claire des stratégies de groupe. Chaque administrateur y va de sa méthode, et au bout d’un moment, on se retrouve soit avec une seule GPO « fourre-tout », soit avec une GPO par action (paramètres, GPP, scripts), ce qui complique la gestion. Il faut parfois des heures pour comprendre quelle GPO fait quoi !
Je ne vous proposerai pas de modèle unique ici, car cela dépend de chaque DSI, mais une règle universelle s’applique : faites preuve de bon sens et organisez vos GPO proprement.
3. Absence de convention de nommage
Toujours dans l’organisation : l’absence de convention de nommage rend difficile l’identification des GPO et de leur portée. Une bonne pratique consiste à :
- Faire commencer les GPO « ordinateur » par la lettre C
- Faire commencer les GPO « utilisateur » par la lettre U
- Donner un nom explicite permettant d’identifier rapidement le rôle de la GPO.
Une convention claire permet aussi d’éviter de mélanger les paramètres utilisateur et ordinateur dans une même GPO, ce qui est fortement déconseillé.
4. Ne pas commenter les GPO et leurs paramètres
Il est fréquent de négliger la description des GPO et de leurs paramètres, pourtant ces champs sont là pour faciliter la compréhension et le suivi.
Prenez l’habitude de documenter chaque GPO : pourquoi elle a été créée, ce qu’elle configure, et éventuellement, les modifications importantes effectuées. Je vous montrerai plus loin où saisir ces commentaires.
5. Mélanger paramètres utilisateur et ordinateur dans une même GPO
Comme évoqué plus haut, créer une GPO qui contient à la fois des paramètres utilisateur et ordinateur pour une même action est une erreur fréquente. Cela traduit souvent un manque de préparation, et on espère que « ça va marcher » en le configurant des deux côtés.
6. Créer une GPO directement liée à une OU en production
Une autre mauvaise pratique consiste à créer une GPO directement au sein de l’unité d’organisation (OU) de production dans laquelle on souhaite l’appliquer. Cela peut sembler pratique sur le moment, mais cela empêche toute phase de test et augmente fortement le risque d’impact en environnement réel.
La bonne approche est la suivante :
- Créer la GPO dans le conteneur « Objets de stratégie de groupe » (via la console GPMC)
- Lier ensuite la GPO à une ou plusieurs OU de test, représentatives de la future cible (ex. : utilisateurs ou machines en pré-production)
- Valider le bon fonctionnement de la GPO en environnement maîtrisé
- Puis seulement lier la GPO aux OU de production
Cela permet d’éviter des erreurs critiques comme des redémarrages inattendus, des restrictions trop fortes, ou des conflits avec des stratégies existantes.
Cette méthode encourage aussi la réutilisation et le contrôle : une GPO bien conçue peut être liée à plusieurs endroits selon les besoins, sans être recréée à chaque fois.
7. Utiliser directement les objets utilisateurs ou ordinateurs pour le filtrage de sécurité
Une erreur fréquente consiste à appliquer une GPO directement à un utilisateur ou un ordinateur spécifique, que ce soit via :
- Le filtrage de sécurité dans les propriétés de la GPO
- Les préférences (GPP) avec ciblage à l’aide de « Nom d’utilisateur » ou « Nom de l’ordinateur »
- Ou même pour refuser l’application d’une GPO à un objet précis
Même si cela peut fonctionner ponctuellement, ce n’est pas recommandé dans une logique de gestion propre et évolutive.
8. Lier les GPO à la racine du domaine sans discernement
Enfin, parlons de la liaison des GPO : il est très courant de voir des GPO liées directement à la racine du domaine, ce qui les applique à tous les objets, y compris aux contrôleurs de domaine.
Posez-vous la question : est-il nécessaire d’appliquer des paramètres de navigateur (ex. Google Chrome) à un contrôleur de domaine, situé en Tier 0, sans accès à Internet ou à d’autres sites internes ?
La réponse est non.
Il est donc crucial de lier les GPO au bon niveau de l’arborescence Active Directory. Parfois, cela implique de lier la même GPO à plusieurs unités d’organisation (OU) en fonction de la structure de votre domaine.
Créer une stratégie de groupe dans l’Active Directory
Après avoir vue ce qu’il ne faut pas faire, on va faire place aux « bonnes pratiques », nous allons le voir, on peut créer une stratégie de groupe en utilisant l’interface graphique de la console Gestion de stratégie de groupe ou en utilisant une invite de commandes PowerShell.
Avant de se lancer dans la création de l’objet GPO, assurer dans un premier temps, d’avoir une unité d’organisation, où vous allez ranger les groupes que vous allez utiliser pour la gestion des stratégies de groupe.
Je pars du principe, que vous savez ce que vous souhaitez faire avec cette stratégies et les paramètres que vous allez modifier, que cela a été testé en LAB et valider.
Créer une stratégie de groupe (GPO) avec la console Gestion de stratégie de groupe
Dans cet article, je parle de création, si vous souhaitez ajouter un paramètre de configuration au niveau Microsoft Edge et que vous avez déjà une stratégie de groupe existante qui configure le navigateur, modifier cet objet plutôt que dans créer un nouveau si la porté est identique.
Aller sur le conteneur (dossier) Objets de stratégie de groupe 1, comme vous pouvez le voir, il contient toutes les stratégies de groupe existante, même celle qui n’ont plus de lien, quand vous supprimez un lien de stratégie de groupe et surtout quand celle-ci à une seule liaison, cela ne supprime l’objet.
Faire un clic droit sur Objets de stratégie de groupe et cliquer sur Nouveau 1.
Nommer 1 le stratégie de groupe en respectant une convention de nommage et cliquer sur le bouton OK 2 pour la créer.
L’objet GPO est créé, faire un clic droit dessus et cliquer sur Modifier 1.
Décrire la stratégie de groupe
Dans les mauvaises pratiques, j’ai parle du manque de description et commentaire des stratégies de groupe, voici comment écrire un commentaire sur une GPO.
Depuis l’éditeur, en étant sélectionnant la stratégie dans le panneau de navigation, cliquer sur Action 1 puis sur Propriétés 2.
Sur l’onglet Commentaire 1, vous avez accès au champ Commentaire 2 qui va permettre de commenter la GPO, pourquoi pas gérer l’historique en indiquant date – auteur : modification …
Commenter les paramètres
On part du principe ou je veux configurer le paramètre : Désactiver l’antivirus Microsoft Defender.
En plus de configurer le paramètre, utiliser le champ commentaire 1 pour expliquer le pourquoi ? pour suivre également les modification, indiquer l’auteur et la date.
Aperçu de la GPO
La stratégie de groupe est créé à ce stade, elle n’est toujours pas active, depuis la console Gestion de stratégie de groupe, on peut voir les commentaires de la GPO et des paramètres.
Créer un groupe de refus de stratégie de groupe
Dans certain cas particulier, il arrive que l’on ait besoin de refuser une application sur un ordinateur ou un utilisateur. Pour anticiper ce cas, on peut créer un groupe qui va nous permettre de bloquer l’application.
Créer un groupe avec un nommage qui permet de lier facilement la stratégie de groupe au groupe et aussi savoir si celui est fait pour appliquer ou refuser.
Ensuite depuis la console Gestion de stratégie de groupe, sur l’objet de stratégie de groupe dans les paramètre de délégation, ajouter une « autorisation » pour le groupe qui permet de lire la stratégie et aussi le refus d’application de la stratégie de groupe.
Tester la stratégie de groupe
Avant la mise en application de la stratégie de groupe, il est conseillé de tester la stratégie sur plusieurs ordinateurs / utilisateurs représentatif de votre environnement.
Commencer par lier la stratégie à un OU de test, pour cela faire un clic droit dessus puis cliquer sur Lier un objet de stratégie de groupe existant 1.
Sélectionner l’objet 1 et cliquer sur OK 2.
La stratégie de group est liée à l’unité d’organisation de Test.
Valider le bon fonctionnement de la stratégie de groupe sur la partie de Test.
Mettre en production la stratégie de groupe
Une fois que tout est validée, lier la stratégie de façon à ce qu’elle s’applique à votre cible et supprimer le lien sur l’OU de Test.
Créer une stratégie de groupe (GPO) avec PowerShell
Si vous souhaitez, il est possible d’utiliser PowerShell pour créer la stratégie de groupe avec le Cmdlet New-GPO et de créer le groupe AD avec la Cmdlet Get-ADGroup.
Pour gagner du temps, voici un script que vous pouvez utiliser, qui va créer la stratégie de groupe, le groupe local Active Directory et placer les autorisations du groupe sur la stratégie de groupe.
Penser juste à modifier la variable $ouPath en indiquant le DN de l’OU où vous placer les groupes.
Import-Module ActiveDirectory
Import-Module GroupPolicy
# Variables
$ouPath = "OU=GPO,OU=Groupes,OU=Lab,DC=lab,DC=lan"
# Demande interactive
$gpoName = Read-Host "Nom de la GPO a creer"
$comment = Read-Host "Commentaire pour la GPO"
$groupName = Read-Host "Nom du groupe AD (etendu local) a exclure"
# Domaine et NetBIOS
$domain = Get-ADDomain
$domainDN = $domain.DistinguishedName
$domainNetBIOS = $domain.NetBIOSName
# Creation groupe si absent
if (-not (Get-ADGroup -Filter "Name -eq '$groupName'" -SearchBase $ouPath -ErrorAction SilentlyContinue)) {
New-ADGroup -Name $groupName `
-SamAccountName $groupName `
-GroupScope DomainLocal `
-GroupCategory Security `
-Path $ouPath `
-ErrorAction Stop
Write-Host "Groupe '$groupName' cree dans '$ouPath'."
} else {
Write-Host "Groupe '$groupName' deja existant."
}
# Creation GPO
$gpo = New-GPO -Name $gpoName -Comment $comment -ErrorAction Stop
Write-Host "GPO '$gpoName' creee."
# Attribution permission lecture sur la GPO
Set-GPPermissions -Name $gpoName -TargetName $groupName -TargetType Group -PermissionLevel GpoRead
Write-Host "Permission lecture accordee au groupe '$groupName' sur la GPO."
# Attente pour replication AD
Start-Sleep -Seconds 10
# Récupération GUID GPO avec accolades, en majuscules
#$gpoGuid = $gpo.Id.Guid.ToString("B").ToUpper()
$gpoGuid = ("{0:B}" -f [Guid]$gpo.Id)
# Construction chemin LDAP GPO
$ldapPath = "LDAP://CN=$gpoGuid,CN=Policies,CN=System,$domainDN"
# Recuperation objet GPO ADSI
$adgpo = [ADSI]$ldapPath
# GUID du droit "Apply Group Policy"
$applyGpoGuid = [Guid]::Parse('edacfd8f-ffb3-11d1-b41d-00a0c968f939')
# Creation regle de refus Apply Group Policy
$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule (
[System.Security.Principal.NTAccount]"$domainNetBIOS\$groupName",
'ExtendedRight',
'Deny',
$applyGpoGuid
)
# Recuperation ACLs existantes
$acl = $adgpo.ObjectSecurity
# Ajout regle de refus
$acl.AddAccessRule($rule)
# Application des modifications
$adgpo.ObjectSecurity = $acl
$adgpo.CommitChanges()
Write-Host "Refus explicite 'Apply Group Policy' ajoute pour '$domainNetBIOS\$groupName' sur la GPO '$gpoName'."Conclusion
A travers cet article, nous avons revu les bonnes pratiques pour mettre en place les stratégies groupe au seins d’un environnement Active Directory.
Quelques liens supplémentaires :
Merci Romain.
Un très bon article qui devrait faire parti des ouvrages qui traitent ce sujet.