Mode opératoire — Les comptes Active Directory

Document autonome. Partie théorique, puis mise en œuvre en ligne de commande sur une installation Server Core, où aucune console graphique n’est disponible.

Dernière mise à jour : 03/10/2026 État au 12/11/2026 : 6 utilisateurs, groupes GG-Direction, GG-Administratif, GG-Technique, DL-Partage-Technique-Modifier (aucun partage de fichiers créé) ; OU Comptes de service et Postes-test ajoutées le 11/11 ; GPO et LAPS : voir MO-20.

Sommaire

1 · Pourquoi la ligne de commande

Sur une installation Server Core, la console Utilisateurs et ordinateurs Active Directory n’existe pas. Il reste trois voies :

L’absence d’interface graphique n’est pas une contrainte, c’est une discipline. Une création de compte faite en PowerShell est reproductible : la commande peut être relue, corrigée, versionnée, rejouée à l’identique sur un autre domaine. Les mêmes clics dans une console ne laissent aucune trace exploitable.

C’est aussi ce qui rend la création en lot possible. Trente comptes à la souris, c’est une heure et deux fautes de frappe ; trente comptes depuis un fichier, c’est une commande.

Vérifier que le module répond :

Get-ADDomain | Format-List DNSRoot, DistinguishedName

Note le DistinguishedName — par exemple DC=sio,DC=internal. Il sert de racine à tous les chemins que tu écriras ensuite.

2 · Conteneur ou unité d’organisation

C’est la notion la plus importante du document, et celle qui coûte le plus cher quand on l’ignore.

Un annuaire fraîchement créé contient déjà des emplacements : CN=Users, CN=Computers, CN=Builtin. Ils ressemblent à des dossiers, ils n’en sont pas.

   sio.internal
     ├── CN=Users          <- conteneur : AUCUNE GPO ne peut s'y lier
     ├── CN=Computers      <- conteneur : idem
     ├── CN=Builtin        <- conteneur : les groupes integres
     └── OU=SIO            <- unite d'organisation : tout devient possible

New-ADUser dépose par défaut dans CN=Users. Si tu ne précises pas -Path, ton compte atterrit dans un conteneur sur lequel aucune stratégie ne pourra jamais s’appliquer — en dehors de celle du domaine entier.

C’est l’erreur classique : créer les comptes, écrire la stratégie, la lier, et constater qu’elle ne produit aucun effet. On cherche alors du côté de la stratégie, qui est pourtant parfaite. Le problème est l’emplacement des comptes.

Le §10 montre comment changer cet emplacement par défaut, pour que l’erreur devienne impossible.

3 · Concevoir l’arborescence avant de créer

3.1 Les trois critères

Une arborescence d’annuaire ne reflète pas l’organigramme pour faire joli. Elle répond à trois questions opérationnelles :

Le découpage se fait selon ce qui diffère, pas selon ce qui existe. Si tous les services reçoivent exactement les mêmes stratégies et sont administrés par les mêmes personnes, les séparer n’apporte rien — c’est de la complexité gratuite. On crée une unité d’organisation quand on a une raison de la traiter différemment.

3.2 Le modèle retenu

   DC=sio,DC=internal
     └── OU=SIO                        racine de l'organisation
           ├── OU=Utilisateurs
           │     ├── OU=Direction
           │     ├── OU=Administratif
           │     └── OU=Technique
           ├── OU=Ordinateurs          les postes de travail (sous-OU Postes-test depuis le 11/11)
           ├── OU=Groupes              les groupes de sécurité
           └── OU=Comptes de service   CS_glpi_ldap (lecture de l'annuaire par GLPI, 11/11)

Ne jamais déplacer les contrôleurs de domaine hors de leur unité OU=Domain Controllers. Une stratégie par défaut y est liée — Default Domain Controllers Policy — et elle porte des réglages de sécurité essentiels. Déplacer un contrôleur, c’est le priver de ces réglages sans aucun avertissement.

4 · Créer les unités d’organisation

$racine = "DC=sio,DC=internal"

New-ADOrganizationalUnit -Name "SIO" -Path $racine
New-ADOrganizationalUnit -Name "Utilisateurs" -Path "OU=SIO,$racine"
New-ADOrganizationalUnit -Name "Ordinateurs"  -Path "OU=SIO,$racine"
New-ADOrganizationalUnit -Name "Groupes"      -Path "OU=SIO,$racine"

foreach ($s in "Direction","Administratif","Technique") {
    New-ADOrganizationalUnit -Name $s -Path "OU=Utilisateurs,OU=SIO,$racine"
}

Lire un chemin d’annuaire

Un DistinguishedName se lit de droite à gauche — du plus général au plus précis :

   OU=Direction , OU=Utilisateurs , OU=SIO , DC=sio , DC=internal
        │               │             │        └───────┬──────┘
        │               │             │                │
      la plus        au-dessus     au-dessus       le domaine
      precise

C’est l’inverse d’un chemin de fichiers, où la racine est à gauche. C’est la source d’erreur numéro un quand on débute : un chemin écrit à l’envers produit un message qui ne dit pas que l’ordre est faux, seulement que l’objet est introuvable.

La protection contre la suppression accidentelle

New-ADOrganizationalUnit active par défaut l’option protégé contre la suppression accidentelle. C’est une bonne chose — et une source de blocage incompréhensible :

Remove-ADOrganizationalUnit -Identity "OU=Technique,OU=Utilisateurs,OU=SIO,$racine"
# Accès refusé  <- alors qu'on est administrateur du domaine

Il faut d’abord lever la protection :

Set-ADOrganizationalUnit -Identity "OU=Technique,OU=Utilisateurs,OU=SIO,$racine" `
                         -ProtectedFromAccidentalDeletion $false

« Accès refusé » alors qu’on est administrateur du domaine est presque toujours cette protection. Elle ne pose pas une question de droits mais une interdiction explicite, posée sur l’objet. Le message, lui, ne le dit pas.

5 · Anatomie d’un compte

Un compte utilisateur porte plusieurs noms, et ils ne servent pas à la même chose. C’est une source de confusion durable tant qu’on ne les a pas distingués.

Les deux identifiants de connexion coexistent, et les deux fonctionnent. SIO\a.gouirand et [email protected] ouvrent la même session. Le premier est hérité des protocoles anciens, le second est aligné sur les usages actuels. Choisis-en un comme convention et tiens-t’y : c’est celui que tu écriras dans les procédures et que les utilisateurs apprendront.

La limite de 20 caractères du SamAccountName est stricte et silencieuse. Un nom composé long est tronqué ou refusé. Une convention courte — initiale du prénom, point, nom — évite le problème dès le départ.

6 · Créer un utilisateur

6.1 La commande

On range les paramètres dans une table de hachage, puis on la passe avec @p (l’arobase, pas le dollar) :

$racine = "DC=sio,DC=internal"
$mdp    = Read-Host "Mot de passe initial" -AsSecureString

$p = @{
  Name                  = "Axel Gouirand"
  GivenName             = "Axel"
  Surname               = "Gouirand"
  DisplayName           = "Axel Gouirand"
  SamAccountName        = "a.gouirand"
  UserPrincipalName     = "[email protected]"
  Path                  = "OU=Technique,OU=Utilisateurs,OU=SIO,$racine"
  AccountPassword       = $mdp
  Enabled               = $true
  ChangePasswordAtLogon = $true
}
New-ADUser @p

Le splatting est la forme recommandée dès qu’une commande dépasse quatre ou cinq paramètres. Une ligne par paramètre, alignés, lisibles ; on ajoute ou retire une ligne sans casser le reste ; et on peut compléter la table conditionnellement avant l’appel.

Les accents graves de continuation sont fragiles : un espace après l’accent grave et tout casse sans message clair. Et une ligne unique de 250 caractères est tronquée par certains terminaux au collage : les derniers paramètres disparaissent, et le message d’erreur parle d’un « paramètre positionnel » sans rapport avec la cause.

-ChangePasswordAtLogon n’est pas un confort, c’est une règle d’hygiène. Tant que l’administrateur connaît le mot de passe d’un utilisateur, aucune action de cet utilisateur ne lui est imputable — il pourrait toujours dire que c’est l’administrateur qui a agi. Le changement au premier accès rétablit cette imputabilité.

Ne jamais écrire le mot de passe dans la commande, même temporairement. Il partirait dans l’historique PowerShell (ConsoleHost_history.txt), lisible en clair, conservé entre les sessions.

6.2 Le mot de passe sera refusé si…

La stratégie de mot de passe du domaine s’applique dès la création. Par défaut :

Le message d’erreur en cas de refus est trompeur : « Le mot de passe ne répond pas aux exigences » arrive parfois sous une forme générique du type « Impossible de définir le mot de passe ». Avant de chercher ailleurs, vérifier que le mot de passe respecte bien la stratégie.

7 · Créer en lot

C’est là que la ligne de commande prend tout son sens.

7.1 Le fichier

utilisateurs.csv, encodé en UTF-8, séparateur point-virgule :

Prenom;Nom;Identifiant;Service
Axel;Gouirand;a.gouirand;Technique
Marie;Durand;m.durand;Direction
Paul;Martin;p.martin;Administratif

7.2 La commande

$racine = "DC=sio,DC=internal"
$mdp    = Read-Host "Mot de passe initial commun" -AsSecureString

Import-Csv .\utilisateurs.csv -Delimiter ";" -Encoding UTF8 | ForEach-Object {
  $p = @{
    Name                  = "$($_.Prenom) $($_.Nom)"
    GivenName             = $_.Prenom
    Surname               = $_.Nom
    DisplayName           = "$($_.Prenom) $($_.Nom)"
    SamAccountName        = $_.Identifiant
    UserPrincipalName     = "$($_.Identifiant)@sio.internal"
    Path                  = "OU=$($_.Service),OU=Utilisateurs,OU=SIO,$racine"
    AccountPassword       = $mdp
    Enabled               = $true
    ChangePasswordAtLogon = $true
  }
  New-ADUser @p
  Write-Host "cree : $($_.Identifiant) dans $($_.Service)"
}

Le Read-Host du mot de passe se colle seul, jamais avec le reste. Il lit la ligne suivante : collé d’un bloc avec la boucle, il avalerait la première ligne comme mot de passe.

La colonne Service fait le travail : elle construit le chemin de l’unité d’organisation. Ajouter un service revient à créer l’unité correspondante et à écrire son nom dans le fichier — aucune modification du script.

Toujours essayer sur deux lignes avant de lancer les trente. Une erreur de chemin ou de convention se répare à la main sur deux comptes ; sur trente, il faut tout supprimer et recommencer.

8 · Les groupes et leurs portées

8.1 Deux classifications à ne pas confondre

Un groupe de distribution ne donne aucun droit. C’est une erreur fréquente : on crée un groupe, on lui attribue des permissions, et rien ne s’applique. Pour donner des droits, il faut -GroupCategory Security.

8.2 Les trois portées

8.3 La règle AGDLP

C’est la méthode canonique d’attribution des droits, et elle tombe régulièrement à l’oral.

   A              G                DL                    P
   Comptes  ──►  groupe Global ──► groupe DomainLocal ──► Permissions
                 (QUI ?)           (SUR QUOI ?)           (la ressource)

Pourquoi passer par deux groupes au lieu d’un seul. Les deux moitiés changent pour des raisons différentes : qui fait partie d’une équipe change souvent ; quelles ressources cette équipe doit atteindre change rarement. En les séparant, une arrivée dans l’équipe se règle en un ajout dans GG-Technique, sans jamais retoucher aux permissions des dossiers.

Avec un seul groupe, chaque nouvelle ressource impose de revoir tous les groupes, et chaque nouvelle personne de vérifier toutes les permissions. C’est ingérable au-delà de quelques dizaines d’utilisateurs — et c’est exactement ce qu’on trouve dans les infrastructures qui ont grandi sans méthode.

8.4 Les commandes

$grp = "OU=Groupes,OU=SIO,DC=sio,DC=internal"

# G — un groupe par role
New-ADGroup -Name "GG-Technique" -GroupScope Global -GroupCategory Security -Path $grp

# DL — un groupe par ressource et niveau d'acces
New-ADGroup -Name "DL-Partage-Technique-Modifier" -GroupScope DomainLocal -GroupCategory Security -Path $grp

# A dans G
Add-ADGroupMember -Identity "GG-Technique" -Members "a.gouirand"

# G dans DL
Add-ADGroupMember -Identity "DL-Partage-Technique-Modifier" -Members "GG-Technique"

Le préfixe dans le nom (GG-, DL-) n’est pas obligatoire mais fortement recommandé. La portée d’un groupe n’apparaît pas dans les listes de permissions d’un dossier : sans convention de nommage, impossible de savoir si on regarde un groupe de rôle ou un groupe de ressource.

9 · Le cycle de vie d’un compte

9.1 Déplacer un objet

Un changement de service est un déplacement, pas une recréation :

Move-ADObject -Identity (Get-ADUser a.gouirand).DistinguishedName `
              -TargetPath "OU=Direction,OU=Utilisateurs,OU=SIO,DC=sio,DC=internal"

Même chose pour une machine — et c’est à faire pour les postes, qui atterrissent par défaut dans CN=Computers :

Move-ADObject -Identity (Get-ADComputer poste-win11).DistinguishedName `
              -TargetPath "OU=Ordinateurs,OU=SIO,DC=sio,DC=internal"

Le déplacement conserve tout : l’identifiant interne (SID), les appartenances aux groupes, le mot de passe, l’historique. Seules les stratégies changent, puisqu’elles dépendent de l’emplacement. C’est exactement l’effet recherché lors d’un changement de service.

9.2 Départ d’un collaborateur — désactiver, pas supprimer

Disable-ADAccount -Identity a.gouirand
Set-ADUser -Identity a.gouirand -Description "Desactive le 03/10/2026 - depart"
Move-ADObject -Identity (Get-ADUser a.gouirand).DistinguishedName `
              -TargetPath "OU=Desactives,OU=SIO,DC=sio,DC=internal"

Supprimer un compte est irréversible dans ses effets, même si l’objet est récupérable. Le SID disparaît — et c’est lui qui figure dans toutes les permissions de fichiers, pas le nom. Un compte recréé à l’identique porte un nouveau SID : il perd l’accès à tout ce que l’ancien pouvait lire.

La procédure canonique est : désactiver, documenter, déplacer, et supprimer plus tard — une fois certain que plus personne n’a besoin de ses fichiers.

9.3 Les gestes courants

Unlock-ADAccount -Identity a.gouirand                         # compte verrouille
Set-ADAccountPassword -Identity a.gouirand -Reset             # reinitialiser
Set-ADUser -Identity a.gouirand -ChangePasswordAtLogon $true  # forcer le changement
Enable-ADAccount -Identity a.gouirand                         # reactiver

Verrouillé n’est pas désactivé. Un compte verrouillé l’a été automatiquement après trop d’échecs d’authentification, et se déverrouille seul après un délai. Un compte désactivé l’a été par un administrateur et le reste. Les deux produisent un refus de connexion, mais ne se traitent pas de la même façon.

10 · Rediriger les emplacements par défaut

Rappel du §2 : sans -Path, un nouvel objet va dans un conteneur où aucune stratégie ne peut s’appliquer. Et une machine qui rejoint le domaine atterrit toujours dans CN=Computers, sans qu’on puisse le lui préciser.

Deux outils règlent le problème définitivement :

redirusr "OU=Utilisateurs,OU=SIO,DC=sio,DC=internal"
redircmp "OU=Ordinateurs,OU=SIO,DC=sio,DC=internal"

redircmp est la commande la plus utile des deux, parce que la jonction au domaine ne permet pas de choisir l’emplacement. Sans elle, chaque poste joint doit être déplacé à la main — et celui qu’on oublie ne reçoit aucune stratégie machine, sans que rien ne le signale.

À exécuter une fois, juste après avoir créé l’arborescence. Le réglage est permanent.

11 · Vérifier et auditer

11.1 Lister ce qu’on vient de créer

Get-ADOrganizationalUnit -Filter * -SearchBase "OU=SIO,DC=sio,DC=internal" |
  Select-Object Name, DistinguishedName

Get-ADUser -Filter * -SearchBase "OU=Utilisateurs,OU=SIO,DC=sio,DC=internal" -Properties Department |
  Select-Object Name, SamAccountName, Enabled, DistinguishedName | Format-Table -AutoSize

11.2 Le contrôle qui évite la mauvaise surprise

Get-ADUser -Filter * -SearchBase "CN=Users,DC=sio,DC=internal" |
  Select-Object Name, SamAccountName

Tout compte qui apparaît ici ne recevra jamais de stratégie autre que celle du domaine. C’est le contrôle à faire après chaque création en lot, et il prend trois secondes. Les comptes intégrés (Administrateur, Invité, krbtgt) y figurent normalement — ce sont les autres qu’il faut déplacer.

11.3 Les comptes à surveiller

Search-ADAccount -AccountDisabled | Select-Object Name, DistinguishedName
Search-ADAccount -LockedOut       | Select-Object Name, LastLogonDate
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 | Select-Object Name, LastLogonDate

Le troisième est celui qu’on ne lance jamais, et qui réserve des surprises. Un compte actif, inutilisé depuis quatre-vingt-dix jours, est au mieux un oubli, au pire une porte ouverte dont plus personne ne surveille l’usage.

12 · L’administration au quotidien

Les sections précédentes décrivent une mise en place : une boucle, six comptes, une fois. Le travail réel d’un administrateur est autre chose : un compte à la fois, et surtout des modifications de comptes existants.

13.1 Créer un seul compte

Le minimum qui fonctionne, sans table de hachage :

New-ADUser -Name "Lucie Blanc" -SamAccountName "l.blanc" -UserPrincipalName "[email protected]" -Path "OU=Direction,OU=Utilisateurs,OU=SIO,DC=sio,DC=internal" -AccountPassword (Read-Host "Mot de passe" -AsSecureString) -Enabled $true -ChangePasswordAtLogon $true

(Read-Host … -AsSecureString) entre parenthèses : la saisie a lieu au moment où PowerShell évalue la parenthèse, donc avant d’exécuter la commande. Pas besoin de variable intermédiaire pour un compte unique.

13.2 Modifier un compte existant

C’est Set-ADUser, et c’est l’essentiel du travail réel.

Set-ADUser l.blanc -Title "Assistante de direction" -Department "Direction" -OfficePhone "0102030405"

Set-ADUser ne touche que ce que tu nommes. Les autres attributs ne bougent pas : on peut enchaîner les corrections sans craindre d’écraser ce qu’on n’a pas mentionné.

13.3 Trouver le nom d’un attribut

C’est la question qui débloque tout le reste :

Get-ADUser l.blanc -Properties * | Format-List

Tous les attributs du compte apparaissent avec leur nom exact. On repère celui qui intéresse, on le passe à Set-ADUser.

Par défaut, Get-ADUser ne renvoie qu’une dizaine d’attributs sur la centaine que porte un compte. Si Department ou LastLogonDate n’apparaissent pas, ils ne sont pas forcément vides : ils n’ont pas été demandés.

Get-ADUser l.blanc -Properties Department, LastLogonDate, MemberOf

13.4 Les gestes courants

12.5 Pourquoi -Path dans les exemples

Les deux outils du §10 règlent l’emplacement par défaut, pas l’emplacement voulu. Écrire -Path reste la façon de dire où ranger le compte. La redirection n’est qu’un filet.

12.6 La console graphique, pour explorer

Un serveur en Core n’a pas de console. Un poste d’administration, lui, peut l’installer :

Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0"
runas /user:SIO\Administrateur "mmc dsa.msc"

Les deux coexistent. La console pour le geste ponctuel et l’exploration, PowerShell pour le volume et tout ce qui doit se reproduire ou se documenter.

Être administrateur local ne donne aucun droit dans l’annuaire. POSTE-WIN11\admin suffit pour installer les outils, pas pour les utiliser : d’où le runas avec un compte du domaine. Ce sont deux autorités distinctes que la jonction ne mélange pas.

L’installation passe par Windows Update et peut sembler figée longtemps. Si elle ne progresse plus, tester la résolution de noms par le résolveur du système, pas seulement en interrogeant les serveurs DNS directement : un échec mémorisé dans le cache du poste (Clear-DnsClientCache) donne exactement ce symptôme.

13 · Pièges et checklists

13.1 Les douze pièges

13.2 Checklist — mise en place de l’annuaire

• Arborescence conçue sur papier avant la première commande
• Racine d’organisation distincte du domaine lui-même
• Utilisateurs, ordinateurs et groupes dans des unités séparées
• Les contrôleurs de domaine laissés dans OU=Domain Controllers
• redirusr et redircmp exécutés
• Convention de nommage écrite : identifiants, groupes, unités

13.3 Checklist — création d’un compte

• -Path renseigné, et vérifié
• SamAccountName conforme à la convention, 20 caractères maximum
• UserPrincipalName cohérent avec le SamAccountName
• Mot de passe saisi masqué, jamais dans la ligne de commande
• -ChangePasswordAtLogon $true
• Appartenances aux groupes posées via le groupe Global de son rôle
• CN=Users contrôlé après coup : le compte n’y est pas

13.4 Checklist — hygiène périodique

• Comptes désactivés : encore utiles ou à supprimer ?
• Comptes inactifs depuis plus de 90 jours identifiés
• Aucun compte applicatif sans propriétaire identifié
• Appartenances aux groupes d’administration relues
• Aucun objet égaré dans CN=Users ou CN=Computers

Le réflexe à garder. Avant chaque création, une seule question : « où est-ce que je le range, et pourquoi là ? » L’emplacement dans l’annuaire n’est pas du classement : c’est lui qui décide des stratégies reçues et des droits d’administration. Un objet bien nommé mais mal rangé est un objet qu’aucune règle n’atteindra.