In this article, I will explain how to create a group policy, also called GPO, while respecting some best practices and errors to avoid in your Active Directory domain.
Table of Contents
Bad practices
Let’s start right away with what I consider to be bad practices in terms of group strategy.
1. Failing to anticipate the group strategy
The first mistake is to not thinking ahead to the group strategy and directly apply parameters without planning. Start by precisely defining what you want to implement. Check if this can be applied at the level user, computer, or bothAnalyze whether the configuration can be achieved via policy settings, a registry modification, or a script.
This first step can be tested locally on a machine via the console. gpedit.msc or in a test environment (Lab).
2. Lack of organization of GPOs
Too often he no clear organization exists group strategies. Each administrator has their own method, and after a while, you end up either with a single “catch-all” GPOThis can be done with a GPO for each action (settings, GPP, scripts), which complicates management. It can sometimes take hours to understand which GPO does what!
I will not propose a single model here, as it depends on each CIO, but a universal rule applies: Use common sense and organize your GPOs properly.
3. Lack of a naming convention
Still on the topic of organization: the absence of naming convention This makes it difficult to identify GPOs and their scope. A good practice is to:
- Start the “computer” GPOs with the letter C
- Start the “user” GPOs with the letter U
- Give a explicit name allowing for the rapid identification of the role of GPO.
A clear agreement also allows to avoid mixing putting user and computer settings in the same GPO is strongly discouraged.
4. Do not comment on GPOs and their settings
It is common to neglecting the description of the GPOs and their parameters, yet these fields are there to facilitate understanding and monitoring.
Make it a habit to document each GPO Why it was created, what it configures, and possibly any significant changes made. I will show you later where to enter these comments.
5. Combine user and computer settings in the same GPO
As mentioned above, create a GPO that contains both user and computer settings for the same action is a common mistake. This often reflects a lack of preparationand we hope that “it will work” by configuring it on both sides.
6. Create a GPO directly linked to a production OU
Another bad practice is to create a GPO directly within the production organizational unit (OU) in which we want to apply it. This may seem convenient at the time, but This prevents any testing phase and greatly increases the risk of impact in a real-world environment.
The correct approach is as follows:
- Create the GPO in the “Group Policy Objects” container (via the GPMC console)
- Next, link the GPO to one or more test OUs.representative of the future target audience (e.g., users or machines in pre-production)
- Validate the proper functioning of the GPO in a controlled environment
- Then only link the GPO to the production OUs
This helps avoid critical errors such as unexpected restarts, overly restrictive settings, or conflicts with existing strategies.
This method also encourages reuse and control : a well-designed GPO can be linked to multiple locations as needed, without being recreated each time.
7. Directly use user devices or computers for security filtering
A common mistake is to apply a GPO directly to a specific user or computer, whether via:
- THE security screening in the GPO properties
- THE preferences (GPP) with targeting using “Username” or “Computer Name”
- Or even for refuse the application from a GPO to a specific object
Even if it might work occasionally, it is not not recommended within a framework of clean and evolving management.
8. Linking GPOs to the domain root indiscriminately
Finally, let’s talk about the linking GPOs It is very common to see GPOs directly linked to the root of the domain, which applies them to all objectsincluding at domain controllers.
Ask yourself the question: is it necessary to apply browser settings (e.g., Google Chrome) to a domain controller, located in Tier 0, without access to the Internet or other internal sites?
The answer is no.
It is therefore crucial to link the GPOs at the correct level of the Active Directory tree structure. Sometimes, this involves link the same GPO to multiple organizational units (OUs) depending on the structure of your domain.
Create a group policy in Active Directory
After seeing what not to do, we will move on to “good practices”, we will see, we can create a group policy using the graphical interface of the Group Policy Management console or using a PowerShell command prompt.
Before embarking on the creation of the GPO object, first ensure that you have an organizational unit where you will store the groups that you will use for managing group policies.
I assume that you know what you want to do with this strategy and the parameters you are going to modify, and that it has been tested in a LAB and validated.
Create a Group Policy Object (GPO) using the Group Policy Management console
In this article, I talk about creating, if you want to add a configuration setting at the Microsoft Edge level and you already have an existing group policy that configures the browser, modify this object rather than creating a new one if the scope is identical.
Go to the container (folder) Group Policy Objects 1, as you can see, it contains all existing group policies, even those that no longer have a link, when you delete a group policy link and especially when it has only one link, this does not delete the object.
Right-click on Group Policy Objects and click on New 1.
Name the group policy 1 according to a naming convention and click the OK button 2 to create it.
The GPO object is created, right-click on it and click on Edit 1.
Describe the group strategy
In the section on bad practices, I talked about the lack of description and commentary on group strategies; here’s how to write a comment on a GPO.
From the editor, by selecting the strategy in the navigation panel, click on Action 1 then on Properties 2.
On the Comment tab 1, you have access to the Comment 2 field which allows you to comment on the GPO, perhaps to manage the history by indicating date – author: modification …
Comment on settings
Let’s assume that I want to configure the setting: Disable Microsoft Defender antivirus.
In addition to configuring the setting, use the comment field 1 to explain the reason? To also track changes, indicate the author and the date.
GPO Overview
The group policy is created at this stage, it is not yet active, from the Group Policy Management console, you can see the comments of the GPO and settings.
Create a group to reject group strategy
In certain specific cases, it may be necessary to block an application on a computer or for a user. To anticipate this, a group can be created that will allow the application to be blocked.
Create a group with a name that makes it easy to link the group strategy to the group and also to know whether it is meant to apply or refuse.
Next, from the Group Policy Management console, on the group policy object in the delegation settings, add an “authorization” for the group that allows reading the policy and also denying the application of the group policy.
Testing the group strategy
Before implementing the group policy, it is advisable to test the policy on several computers/users representative of your environment.
Start by linking the policy to a test OU, to do this right-click on it and then click on Link an existing group policy object 1.
Select object 1 and click OK 2.
The group strategy is linked to the Test organizational unit.
Validate the proper functioning of the group strategy on the Test part.
Putting the group strategy into production
Once everything is validated, link the strategy so that it applies to your target and remove the link on the Test OU.
Create a Group Policy Object (GPO) with PowerShell
If you wish, it is possible to use PowerShell to create the group policy with the cmdlet. New-GPO and to create the AD group with the cmdlet Get-ADGroup.
To save time, here is a script you can use, which will create the group policy, the local Active Directory group and place the group permissions on the group policy.
Just remember to change the variable $orPath indicating the DN of the OU where you place the groups.
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
In this article, we have reviewed best practices for implementing group strategies within an Active Directory environment.
