Création d'un utilisateur dans l'Active Directory

Contexte et besoins

Dans le cadre de mon alternance, j’interviens sur l’Active Directory du lab interne, monté sur un Windows Server 2022 qui héberge le domaine LAB.LOCAL. C’est l’environnement utilisé pour rejouer les opérations d’administration courante avant de les passer en production.

L’objectif de cette intervention est simple : créer proprement un compte utilisateur pour un nouveau collaborateur, Jean Dupont, qui doit pouvoir s’authentifier sur le domaine. Je veux maîtriser les deux chemins : l’interface graphique (ADUC) que j’utilise au quotidien, et la version PowerShell que je veux apprendre pour scripter ces tâches plus tard. Pas encore d’OU dédiée par service : je travaille dans le container Users par défaut, en assumant que la structuration en OU sera l’objet d’une intervention ultérieure.

Rappel théorique sur Active Directory

Active Directory Domain Services (AD DS) est le service d’annuaire Microsoft, intégré à Windows Server. Il s’appuie sur des standards ouverts (LDAP pour l’accès, Kerberos pour l’authentification) mais y ajoute des éléments propres à l’écosystème Microsoft (GPO, replication multi-maître entre contrôleurs de domaine, schéma extensible).

Structure logique

• Forêt : ensemble d’arbres partageant un schéma et un catalogue global.
• Domaine : unité de réplication et de sécurité. Ici, LAB.LOCAL.
• Conteneur : objet qui regroupe d’autres objets. CN=Users et CN=Computers sont créés par défaut.
• Unité d’organisation (OU) : container hiérarchique sur lequel on peut appliquer des GPO, déléguer l’administration. Distincte d’un container simple.
• Objet utilisateur : classe user dans le schéma, avec une centaine d’attributs possibles.

Attributs clés d’un utilisateur

Authentification : Kerberos > NTLM

Quand l’utilisateur ouvre une session, Windows négocie d’abord Kerberos (port 88). Le client demande un Ticket Granting Ticket (TGT) au KDC du domaine, puis l’utilise pour obtenir des tickets de service. NTLM reste un secours pour les scénarios non-domaine ou les protocoles legacy, mais on s’oriente vers du Kerberos pur dès qu’on peut, conformément aux recommandations ANSSI.

Topologie

Le contrôleur de domaine du lab tourne dans une VM, sur le même segment d’administration que mon poste depuis lequel j’ouvre la console ADUC.

Prérequis

• Un contrôleur de domaine LAB.LOCAL opérationnel (forêt et domaine déjà promus).
• Le rôle Active Directory Domain Services installé.
• Les outils RSAT installés sur le poste d’admin, ou à défaut une session RDP sur le DC.
• Un compte d’administration de domaine (membre de Domain Admins ou disposant des droits délégués sur le container Users).

Ouverture de la console ADUC

Sur le DC, je lance Outils d’administration → Utilisateurs et ordinateurs Active Directory (dsa.msc). La console affiche l’arborescence du domaine LAB.LOCAL avec les containers par défaut :

• Builtin
• Computers
• Domain Controllers
• ForeignSecurityPrincipals
• Managed Service Accounts
• Users

Je travaille dans Users. Pour un environnement plus mature, on créerait une OU dédiée (par exemple OU=Utilisateurs,DC=LAB,DC=LOCAL) afin de pouvoir lui appliquer des GPO spécifiques ; je le note pour une prochaine intervention.

Création de l’utilisateur via ADUC

Clic droit sur le container Users → Nouveau → Utilisateur. Une fenêtre Nouvel objet - Utilisateur s’ouvre.

Identité

Créer dans : LAB.LOCAL/Users
Prénom     : Jean
Initiales  : (vide)
Nom        : Dupont
Nom complet: Jean Dupont

Nom d'ouverture de session de l'utilisateur     : jean.dupont @LAB.LOCAL
Nom d'ouverture de session (antérieur Windows 2000) : LAB\jdupont

Explications ligne par ligne :

• Prénom / Nom / Nom complet : alimentent respectivement les attributs givenName, sn et cn. Le cn doit être unique dans le container parent : deux Jean Dupont dans le même Users provoquerait une erreur, il faut alors différencier (par exemple Jean Dupont (IT)).
• Nom d'ouverture de session de l'utilisateur : le UPN, format moderne login@domaine. Ici je saisis jean.dupont, qui devient jean.dupont@LAB.LOCAL.
• Nom d'ouverture de session (antérieur Windows 2000) : le sAMAccountName, plus court (≤ 20 caractères), ici jdupont (initiale du prénom + nom). C’est le format que Windows utilise encore pour la plupart des protocoles internes (SMB, partages, GPO).

Mot de passe et options de compte

L’écran suivant demande le mot de passe initial.

Mot de passe              : ●●●●●●●●●●
Confirmer le mot de passe : ●●●●●●●●●●

[X] L'utilisateur doit changer le mot de passe à la prochaine ouverture de session
[ ] L'utilisateur ne peut pas changer de mot de passe
[ ] Le mot de passe n'expire jamais
[ ] Le compte est désactivé

Explications ligne par ligne :

• Mot de passe : doit respecter la politique de mot de passe du domaine par défaut : 7 caractères minimum, complexité activée (3 catégories sur 4 parmi majuscules, minuscules, chiffres, caractères spéciaux). Sur un domaine de production, on durcit cette politique via Default Domain Policy ou une Fine-Grained Password Policy.
• L'utilisateur doit changer le mot de passe à la prochaine ouverture : coché. Le mot de passe que je saisis est temporaire, l’utilisateur définira le sien au premier login. C’est l’attribut pwdLastSet mis à 0, qui force le changement.
• Le mot de passe n'expire jamais : non coché. Ce flag (bit 65536 de userAccountControl) est explicitement déconseillé par les guides ANSSI sauf cas de comptes de service spécifiques.
• Le compte est désactivé : non coché. Si on coche, l’utilisateur ne peut pas se logger : utile pour préparer un compte avant l’arrivée effective.

Date d’expiration du compte

Une fois le compte créé, j’ouvre les Propriétés de Jean Dupont, onglet Compte, pour fixer une date d’expiration.

Options de compte:
  [X] L'utilisateur devra changer le mot de passe à la prochaine ouverture
  [ ] L'utilisateur ne peut pas changer de mot de passe
  [ ] Le mot de passe n'expire jamais
  [ ] Enregistrer le mot de passe en utilisant un chiffrement réversible

Date d'expiration du compte:
  ( ) Jamais
  (•) Fin de : vendredi 17 avril 2026

Explications :

• Date d'expiration: vendredi 17 avril 2026 : alimente l’attribut accountExpires. Au-delà, le compte est automatiquement désactivé. C’est utile pour les contrats à durée déterminée, les stagiaires, les prestataires : ça évite les comptes orphelins qui survivent à la fin de mission.
• Chiffrement réversible : jamais coché. Ce flag fait que Windows conserve le mot de passe en clair (chiffrement réversible AD). C’est indispensable pour certains protocoles legacy (CHAP, MS-CHAPv2) mais constitue un risque majeur. À éviter sauf nécessité absolue, et à compenser par d’autres mesures.

Création de l’utilisateur via PowerShell

Pour automatiser le geste, je rejoue la même création depuis une console PowerShell sur le DC, en chargeant le module ActiveDirectory.

# Définir le mot de passe initial sous forme de SecureString
$MotDePasse = ConvertTo-SecureString "Tmp!2025Dupont" -AsPlainText -Force

# Création du compte
New-ADUser `
    -Name "Jean Dupont" `
    -GivenName "Jean" `
    -Surname "Dupont" `
    -DisplayName "Jean Dupont" `
    -SamAccountName "jean.dupont" `
    -UserPrincipalName "jean.dupont@LAB.LOCAL" `
    -Path "CN=Users,DC=LAB,DC=LOCAL" `
    -AccountPassword $MotDePasse `
    -ChangePasswordAtLogon $true `
    -AccountExpirationDate "2026-04-17" `
    -Enabled $true

Explications ligne par ligne :

• ConvertTo-SecureString -AsPlainText -Force : convertit la chaîne en SecureString (objet chiffré en mémoire). PowerShell rouspète sur -AsPlainText parce que ce n’est pas idéal de mettre un mot de passe en dur dans un script ; pour un script de production, on lirait depuis un coffre-fort ou via Read-Host -AsSecureString.
• -Name : alimente le cn (= nom complet visible dans ADUC).
• -SamAccountName et -UserPrincipalName : sur la version PowerShell, je mets jean.dupont partout pour ne pas avoir deux libellés différents pour le même compte (jdupont côté pré-Windows 2000, jean.dupont côté UPN comme dans la capture ADUC).
• -Path : le DN du container parent. Ici CN=Users,DC=LAB,DC=LOCAL correspond bien au container Users par défaut.
• -ChangePasswordAtLogon $true : équivaut à la case ADUC.
• -AccountExpirationDate "2026-04-17" : date au format ISO. Conforme à l’attribut accountExpires.
• -Enabled $true : le compte est activé immédiatement. Sans ce switch, New-ADUser crée le compte désactivé par défaut, ce qui est parfois un bon comportement pour préparer le compte avant l’arrivée.

Vérifications

Trois contrôles pour s’assurer que le compte est bien créé et utilisable.

Lecture des attributs

Get-ADUser -Identity "jean.dupont" -Properties DisplayName,UserPrincipalName,AccountExpirationDate,PasswordLastSet,Enabled |
    Format-List Name,SamAccountName,UserPrincipalName,DisplayName,AccountExpirationDate,PasswordLastSet,Enabled

Sortie attendue :

Name                  : Jean Dupont
SamAccountName        : jean.dupont
UserPrincipalName     : jean.dupont@LAB.LOCAL
DisplayName           : Jean Dupont
AccountExpirationDate : 17/04/2026 00:00:00
PasswordLastSet       :
Enabled               : True

PasswordLastSet est vide : c’est le marqueur du flag « doit changer le mot de passe à la prochaine ouverture ».

Test d’authentification

Sur un poste joint au domaine LAB.LOCAL, je tente une session avec jean.dupont et le mot de passe initial. Windows m’invite à le changer immédiatement, comme prévu. Une fois le nouveau mot de passe défini, la session s’ouvre.

Lecture en LDAP brut

$Cible = [ADSI]"LDAP://CN=Jean Dupont,CN=Users,DC=LAB,DC=LOCAL"
$Cible.userAccountControl
$Cible.accountExpires

Le userAccountControl retourne 512 (valeur normale d’un compte actif), accountExpires retourne le timestamp Windows correspondant au 17/04/2026.

Problèmes rencontrés et solutions

Compétences du bloc 1 mobilisées

Bilan

À l’issue de la séance, Jean Dupont est un utilisateur authentifiable sur LAB.LOCAL, avec une date d’expiration alignée sur sa date de fin de contrat, un mot de passe à renouveler au premier login, et son userAccountControl à 512 qui confirme un compte actif normal. Côté méthode, j’ai retenu trois points :

• garder un libellé unique sAMAccountName / UPN dès la création évite d’avoir deux logins concurrents pour le même utilisateur ;
• l’accountExpires est un outil très simple pour fiabiliser la sortie d’un collaborateur en CDD, beaucoup plus robuste qu’un rappel calendrier ;
• la version PowerShell est nettement plus rapide à rejouer, et c’est elle qui sera utile dès qu’on devra créer plusieurs comptes d’un coup (boucle sur un CSV, par exemple).

Pour la suite, je veux structurer le domaine en OU par service, puis appliquer une GPO spécifique par OU pour avoir un cadre prêt à recevoir une vraie petite organisation.

Sources

• Microsoft Learn — Active Directory Domain Services Overview , Microsoft.
• Microsoft Learn — New-ADUser (ActiveDirectory module) , Microsoft.
• Microsoft Learn — userAccountControl flags , Microsoft.
• RFC 4511 — Lightweight Directory Access Protocol (LDAP): The Protocol , IETF, 2006.
• ANSSI — Recommandations de sécurité relatives à Active Directory , ANSSI.