Concevoir le schéma d’OU, comptes et groupes Active Directory pour une PME

Un Active Directory mal structuré ne devient jamais propre tout seul. Les unités d’organisation, les groupes et les conventions de nommage doivent être pensés avant le premier compte utilisateur. Une fois 50 utilisateurs créés dans Users par défaut, une fois 30 GPO posées au mauvais endroit, une fois six niveaux d’OU emboîtés, refactoriser coûte plusieurs jours.

Ce tutoriel pose la structure que toute PME peut adopter telle quelle, ou adapter. On y voit : la séparation par type d’objet et par fonction métier, le modèle AGDLP de gestion des permissions, les conventions de nommage, la délégation au help-desk, et un script PowerShell qui crée tout en quelques secondes.

Prérequis : avoir un domaine AD opérationnel (cf. Promouvoir le premier contrôleur de domaine Active Directory). Vue d’ensemble : Windows Server 2025 et Active Directory pour PME.

Prérequis

• Un domaine Active Directory fonctionnel avec au moins un DC promu.
• Un compte membre de Domain Admins (typiquement Administrator du domaine).
• Le module PowerShell ActiveDirectory installé (déjà présent sur un DC via RSAT-AD-Tools).
• Une vision arrêtée du périmètre métier de l’entreprise : combien de fonctions distinctes (commercial, technique, comptabilité, direction), combien de sites.
• Niveau attendu : débutant à intermédiaire.
• Temps estimé : 30 à 45 minutes pour la conception, 5 minutes pour l’exécution du script.

Étape 1 — Comprendre pourquoi ne pas utiliser les conteneurs par défaut

Quand un compte ou un ordinateur rejoint le domaine sans cible explicite, AD les place dans deux conteneurs intégrés : CN=Users et CN=Computers. Or ces conteneurs ne sont pas des unités d’organisation : aucune GPO ne peut leur être appliquée directement. Toute politique reposant sur ces emplacements est ignorée silencieusement.

La première chose à faire après la promotion du domaine est de rediriger les créations par défaut vers de vraies OU :

redirusr 'OU=Utilisateurs,DC=ad,DC=entreprise,DC=com'
redircmp 'OU=Postes,DC=ad,DC=entreprise,DC=com'

À partir de ce moment, tout nouveau compte créé via net user, et tout poste joignant le domaine sans cible, atterriront dans des OU sur lesquelles les GPO peuvent agir. À noter : les commandes échouent si les OU cibles n’existent pas encore — on les crée donc avant.

Étape 2 — Choisir la structure d’OU

L’erreur la plus fréquente est de calquer l’OU sur l’organigramme : Direction, Service technique, Comptabilité… Cette structure est intuitive mais elle se révèle vite ingérable : un même utilisateur change d’équipe (déplacement), un commercial doit aussi être traité comme un mobile (deux politiques contradictoires), une OU contient des comptes ET des postes ET des groupes (impossible de cibler une GPO côté ordinateur uniquement).

La structure efficace combine deux axes :

• Premier niveau : type d’objet — Utilisateurs, Postes, Serveurs, Groupes, Comptes-Service.
• Deuxième niveau : fonction métier ou site — Commerce, Technique, Direction, ou Paris, Lyon.

Le schéma minimal pour une PME de 50 postes :

ad.entreprise.com
├── OU=Utilisateurs
│   ├── OU=Commerce
│   ├── OU=Technique
│   ├── OU=Direction
│   └── OU=Comptes-Desactives
├── OU=Postes
│   ├── OU=Bureaux
│   └── OU=Portables
├── OU=Serveurs
│   ├── OU=Applicatifs
│   └── OU=Infrastructure
├── OU=Groupes
│   ├── OU=Securite
│   └── OU=Distribution
└── OU=Comptes-Service

Cette arborescence cible naturellement les GPO : Configuration ordinateur sur OU=Postes pour BitLocker et AppLocker, Configuration utilisateur sur OU=Utilisateurs/OU=Commerce pour le mappage des lecteurs commerciaux, etc.

Étape 3 — Convention de nommage

Une convention claire évite la pollution d’AD au fil des années. Quatre règles à graver dans la documentation :

• SamAccountName utilisateur : prenom.nom en minuscules, sans accent, sans espace. Maximum 20 caractères (limite NetBIOS). Exemple : marie.dupont.
• UPN (User Principal Name) : prenom.nom@entreprise.com, identique à l’adresse e-mail Microsoft 365 pour faciliter le SSO. Attention : différent du suffixe AD interne ad.entreprise.com.
• Nom de groupe : préfixe par type. GG- pour groupe global, DL- pour domain local, UN- pour universel. Suivi du métier : GG-Commerce, DL-Partage-Compta-RW.
• Nom de poste : PC-001, PC-002 pour les bureautique, NB-001 pour les notebooks, SRV-FILES01 pour les serveurs. Limite NetBIOS 15 caractères majuscules.

Étape 4 — Le modèle AGDLP en pratique

Le modèle Account → Global → Domain Local → Permission codifie une bonne pratique vieille de 20 ans : on n’attribue jamais une permission directement à un compte utilisateur. On regroupe les comptes par fonction dans des groupes globaux, on regroupe les permissions par ressource dans des groupes domaine local, et on imbrique les globaux dans les domaine locaux.

Exemple concret pour un partage de fichiers Compta :

• Compte utilisateur marie.dupont → membre du groupe global GG-Compta.
• Le partage \\SRV-FILES01\Compta$ a un ACL : DL-Partage-Compta-RW en modification.
• Le groupe DL-Partage-Compta-RW contient le groupe global GG-Compta.

Quand un nouveau membre arrive en compta, on l’ajoute uniquement à GG-Compta et il hérite automatiquement de tous les accès. Quand on rénove le partage, on modifie l’ACL d’un seul groupe DL. Aucune permission n’a jamais à toucher un compte individuel.

Étape 5 — Créer l’arborescence d’OU en PowerShell

Le module ActiveDirectory expose New-ADOrganizationalUnit. On le scripte pour créer la structure en une seule exécution. Notez le paramètre -ProtectedFromAccidentalDeletion qui empêche la suppression par mégarde — coche par défaut depuis Server 2008 R2, on la garde activée.

Import-Module ActiveDirectory
$domainDn = (Get-ADDomain).DistinguishedName

# Premier niveau
'Utilisateurs','Postes','Serveurs','Groupes','Comptes-Service' | ForEach-Object {
  New-ADOrganizationalUnit -Name $_ -Path $domainDn `
    -ProtectedFromAccidentalDeletion $true
}

# Sous-OU Utilisateurs
'Commerce','Technique','Direction','Comptes-Desactives' | ForEach-Object {
  New-ADOrganizationalUnit -Name $_ `
    -Path "OU=Utilisateurs,$domainDn" `
    -ProtectedFromAccidentalDeletion $true
}

# Sous-OU Postes
'Bureaux','Portables' | ForEach-Object {
  New-ADOrganizationalUnit -Name $_ `
    -Path "OU=Postes,$domainDn" `
    -ProtectedFromAccidentalDeletion $true
}

# Sous-OU Serveurs
'Applicatifs','Infrastructure' | ForEach-Object {
  New-ADOrganizationalUnit -Name $_ `
    -Path "OU=Serveurs,$domainDn" `
    -ProtectedFromAccidentalDeletion $true
}

# Sous-OU Groupes
'Securite','Distribution' | ForEach-Object {
  New-ADOrganizationalUnit -Name $_ `
    -Path "OU=Groupes,$domainDn" `
    -ProtectedFromAccidentalDeletion $true
}

Vérifier ensuite avec :

Get-ADOrganizationalUnit -Filter * | Select-Object Name, DistinguishedName

L’arborescence doit être complète. Si l’une des OU manque, vérifier que le compte utilisé est bien Domain Admin et que la commande New-ADOrganizationalUnit ne renvoie pas une erreur silencieuse (typiquement, un caractère interdit dans le nom).

Étape 6 — Rediriger Users et Computers

Maintenant que les OU cibles existent, on lance les redirections :

redirusr 'OU=Utilisateurs,DC=ad,DC=entreprise,DC=com'
redircmp 'OU=Postes,DC=ad,DC=entreprise,DC=com'

Adapter les DC= à votre nom de domaine. Vérifier avec ADUC ou en interrogeant la propriété wellKnownObjects du domaine :

(Get-ADDomain).UsersContainer
(Get-ADDomain).ComputersContainer

Les sorties doivent désormais pointer sur les OU, pas sur CN=Users/CN=Computers.

Étape 7 — Créer les groupes de sécurité globaux

Les groupes globaux portent l’appartenance fonctionnelle. On en crée un par fonction métier :

$gPath = "OU=Securite,OU=Groupes,$domainDn"

'GG-Commerce','GG-Technique','GG-Direction','GG-Tous' | ForEach-Object {
  New-ADGroup -Name $_ -GroupScope Global -GroupCategory Security `
    -Path $gPath -Description "Groupe global metier $($_.Substring(3))"
}

Le groupe GG-Tous est l’équivalent métier de Domain Users mais avec un nommage que vos collaborateurs comprennent quand ils voient un partage Lecteur K – accessible a GG-Tous. Une bonne pratique : créer un script de provisionnement utilisateur qui ajoute automatiquement chaque nouveau compte à GG-Tous et au groupe métier approprié.

Étape 8 — Créer un compte utilisateur test

Tester la chaîne complète avec un compte pilote. La création d’un utilisateur en PowerShell se fait en une commande :

$pwd = Read-Host -AsSecureString 'Mot de passe initial'

New-ADUser -Name 'Marie Dupont' `
  -SamAccountName 'marie.dupont' `
  -UserPrincipalName 'marie.dupont@entreprise.com' `
  -GivenName 'Marie' -Surname 'Dupont' `
  -DisplayName 'Marie Dupont' `
  -EmailAddress 'marie.dupont@entreprise.com' `
  -Path "OU=Commerce,OU=Utilisateurs,$domainDn" `
  -AccountPassword $pwd `
  -ChangePasswordAtLogon $true `
  -Enabled $true

Add-ADGroupMember -Identity 'GG-Commerce' -Members 'marie.dupont'
Add-ADGroupMember -Identity 'GG-Tous' -Members 'marie.dupont'

Le paramètre ChangePasswordAtLogon force le changement à la première ouverture, ce qui évite que le mot de passe initial reste connu de l’admin. Le compte est immédiatement utilisable sur n’importe quel poste joint au domaine.

Étape 9 — Déléguer le help-desk sans donner Domain Admin

Le réflexe naturel — ajouter l’équipe help-desk à Domain Admins — est une faute lourde. On crée un groupe dédié GG-HelpDesk et on lui délègue des droits granulaires sur l’OU Utilisateurs :

• Réinitialiser les mots de passe et débloquer les comptes ;
• Modifier le numéro de téléphone, le service, l’adresse ;
• Ajouter/retirer un utilisateur dans certains groupes uniquement.

La délégation se configure via l’assistant Delegation of Control dans Active Directory Users and Computers (clic droit sur OU → Delegate Control). En PowerShell, on passe par dsacls :

$groupSid = (Get-ADGroup 'GG-HelpDesk').SID
dsacls "OU=Utilisateurs,$domainDn" /I:S /G "$($groupSid):CA;Reset Password;user"
dsacls "OU=Utilisateurs,$domainDn" /I:S /G "$($groupSid):WP;pwdLastSet;user"

Tester ensuite avec un membre du help-desk : il doit pouvoir réinitialiser un mot de passe mais pas créer un nouveau compte ou modifier l’appartenance aux groupes admin.

Étape 10 — Gérer les comptes de service correctement

Les comptes de service sont les comptes utilisés par les applications pour s’authentifier auprès d’AD : un service de sauvegarde, un connecteur Entra ID, un agent de supervision Zabbix. Historiquement, ces comptes étaient créés comme des utilisateurs ordinaires avec mot de passe stable, ce qui en faisait des cibles privilégiées pour les attaquants. Les services Active Directory modernes apportent deux mécanismes nettement supérieurs :

• Managed Service Account (MSA) — compte machine spécifique, mot de passe géré automatiquement par AD, lié à une seule machine. Utile pour un service qui ne tourne que sur un serveur.
• Group Managed Service Account (gMSA) — version étendue, utilisable depuis plusieurs serveurs simultanément. C’est la solution moderne pour les services en cluster ou les fermes.

Pour créer un gMSA, il faut d’abord générer une clé racine KDS (une seule fois par forêt). En production, on utilise -EffectiveImmediately et on attend les 10 heures de propagation que les DC imposent pour garantir que la clé est répliquée partout avant de servir des gMSA. La variante -EffectiveTime ((Get-Date).AddHours(-10)) existe mais elle est explicitement documentée par Microsoft comme un raccourci réservé aux environnements de test qui contourne cette sécurité de propagation — à proscrire en production.

# PRODUCTION (attendre 10 heures avant la première utilisation gMSA)
Add-KdsRootKey -EffectiveImmediately

# Test/lab uniquement (bypasse l'attente de 10 heures)
# Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

New-ADServiceAccount -Name 'gmsa-backup' `
  -DNSHostName 'gmsa-backup.ad.entreprise.com' `
  -PrincipalsAllowedToRetrieveManagedPassword 'SRV-FILES01$', 'SRV-FILES02$' `
  -Path "OU=Comptes-Service,$domainDn"

Les serveurs autorisés récupèrent automatiquement le mot de passe en mémoire et le service s’authentifie sans qu’aucun humain ne connaisse ce mot de passe. Pour la suite, on bannit progressivement les comptes utilisateurs classiques au profit des gMSA dès qu’une application le supporte.

Étape 11 — Adopter le modèle Tier 0 / Tier 1 / Tier 2

Microsoft a formalisé un modèle de séparation des privilèges connu sous le nom Enhanced Security Administrative Environment, plus simplement appelé modèle Tier :

• Tier 0 — Domain Controllers et infrastructure d’identité (AD, ADFS, Entra Connect, Azure AD Sync). Les comptes Tier 0 ne se connectent JAMAIS à un poste utilisateur ni à un serveur applicatif.
• Tier 1 — Serveurs applicatifs (file servers, ERP, SQL, sauvegarde). Comptes admin distincts qui n’accèdent jamais au Tier 0 ni aux postes Tier 2.
• Tier 2 — Postes utilisateurs et help-desk. Les techniciens utilisent leur compte Tier 2 pour intervenir sur les postes, jamais sur un serveur Tier 1.

Côté annuaire, on matérialise ce modèle par trois OU dédiées dans Utilisateurs : Administrateurs-T0, Administrateurs-T1, Administrateurs-T2. Chaque administrateur reçoit deux comptes : son compte de bureautique standard (pour ouvrir Outlook et naviguer) et son compte de Tier (jamais utilisé hors interventions). Les GPO appliquent des restrictions Deny logon qui empêchent un compte Tier 0 de s’authentifier sur un poste Tier 2.

Mettre en place le modèle complet prend une journée de configuration, mais c’est l’une des protections les plus efficaces contre la propagation latérale d’une compromission.

Étape 12 — Documenter l’arborescence

Aucune structure AD ne survit deux ans sans documentation. Exporter l’arbre actuel :

Get-ADOrganizationalUnit -Filter * |
  Select-Object DistinguishedName, Name |
  Export-Csv -Path 'C:\Admin\ad-ou-export.csv' -NoTypeInformation -Encoding UTF8

Get-ADGroup -Filter * -Properties Members |
  Select-Object Name, GroupScope, GroupCategory, @{n='Members';e={$_.Members.Count}} |
  Export-Csv -Path 'C:\Admin\ad-groupes-export.csv' -NoTypeInformation -Encoding UTF8

Joindre ces exports à la documentation IT de l’entreprise. Idéalement, une tâche planifiée hebdomadaire régénère ces fichiers et les archive.

Au-delà de la cartographie technique, documenter aussi la logique métier : pourquoi tel groupe existe, quels accès il porte, qui est habilité à en faire évoluer la composition. Cette documentation reste utile cinq ans plus tard quand l’auteur initial a quitté l’entreprise et que personne ne sait plus pourquoi GG-Compta-Bilans existe à côté de GG-Compta. Un simple wiki Confluence, Notion ou un Markdown dans le dépôt Git de l’IT suffit, du moment que tout le monde sait où il est et qu’il est tenu à jour.

Une dernière bonne pratique : créer un compte de service en lecture seule (par exemple svc-readonly) dédié aux outils d’inventaire et d’audit comme PingCastle ou BloodHound. Ce compte interroge l’annuaire sans aucune permission d’écriture, et ses traces dans les journaux sont aisément identifiables lors d’un audit de sécurité, ce qui distingue clairement les requêtes légitimes des reconnaissances offensives potentielles.

Erreurs fréquentes

Vérification finale

L’annuaire est désormais structuré : six OU principales, sous-OU métier, redirections appliquées, premiers groupes globaux créés, un compte pilote testé, délégation help-desk fonctionnelle. Vous pouvez maintenant ajouter des centaines d’utilisateurs en gardant la cohérence et appliquer les GPO sereinement.

La suite naturelle : poser les GPO essentielles pour PME sur ces OU. Pour le DNS qui sous-tend tout : DNS intégré à Active Directory. Pour le panorama : Windows Server 2025 et Active Directory pour PME.

Ressources officielles

• Best practices for securing Active Directory — Microsoft Learn
• ActiveDirectory PowerShell module reference — Microsoft Learn
• Redirecting the Users and Computers containers — Microsoft Learn
• Delegate administrator account — Microsoft Learn