Windows Server 2025 / Créer des utilisateurs, groupes et UO dans AD

Dans Active Directory (AD), les utilisateurs, groupes et unités d'organisation (UO) remplissent des rôles distincts. Les UO organisent les objets pour la délégation et l'application des stratégies ; les groupes de sécurité servent à attribuer des autorisations aux ressources. Gérer l'accès par groupe facilite la vérification des changements par rapport à des autorisations attribuées à chaque utilisateur.

Planifiez des UO propres au laboratoire

Sous ad.example.test, créez Lab avec LabUsers, LabGroups, Workstations et Servers. Gardez-les séparés des conteneurs par défaut Users et Computers. Ne déplacez pas arbitrairement les comptes administratifs intégrés, les identités de services ou les contrôleurs hors de Domain Controllers.

Concevez les UO selon les besoins de délégation et l'étendue des stratégies de groupe, sans reproduire mécaniquement l'organigramme. Trop de niveaux compliquent le suivi des héritages. Conservez la protection contre la suppression accidentelle sur les nouvelles UO.

Créez l'utilisateur et le groupe dans l'interface graphique

1. Sur DC1 ou un poste doté des outils d’administration à distance (RSAT) et autorisé, ouvrez dsa.msc.
2. Dans le domaine ad.example.test, créez Lab, puis les quatre UO enfants indiquées dans le tableau.
3. Créez labuser1 dans LabUsers avec un mot de passe initial unique conforme à la stratégie du domaine et imposez son changement à la prochaine connexion.
4. Dans LabGroups, créez GG_LabUsers comme groupe de sécurité à étendue globale.
5. Ajoutez labuser1 au groupe et vérifiez l'appartenance dans les propriétés du groupe et du compte utilisateur.

Utilisez un groupe de sécurité, et non un groupe de distribution, pour attribuer des autorisations. L'étendue dépend des membres et des domaines concernés ; ce laboratoire avec un seul domaine commence par un groupe global. Consultez New-ADGroup.

Reproduisez la configuration avec PowerShell

Utilisez l'alternative suivante uniquement si vous n'avez pas déjà créé ces objets dans l'interface graphique. Exécutez-la sur DC1 ou un poste autorisé doté du module Active Directory. Si un nom existe déjà, examinez son objet et son usage avant toute modification :

Import-Module ActiveDirectory
$domainPath = 'DC=ad,DC=example,DC=test'
$labPath = 'OU=Lab,' + $domainPath
New-ADOrganizationalUnit -Name 'Lab' -Path $domainPath -ProtectedFromAccidentalDeletion $true
foreach ($ouName in 'LabUsers','LabGroups','Workstations','Servers') {
    New-ADOrganizationalUnit -Name $ouName -Path $labPath -ProtectedFromAccidentalDeletion $true
}
$initialPassword = Read-Host 'Initial password for labuser1' -AsSecureString
New-ADUser -Name 'Lab User One' -SamAccountName 'labuser1' -UserPrincipalName 'labuser1@ad.example.test' -Path ('OU=LabUsers,' + $labPath) -AccountPassword $initialPassword -Enabled $true -ChangePasswordAtLogon $true
New-ADGroup -Name 'GG_LabUsers' -GroupCategory Security -GroupScope Global -Path ('OU=LabGroups,' + $labPath)
Add-ADGroupMember -Identity 'GG_LabUsers' -Members 'labuser1'
Get-ADGroupMember -Identity 'GG_LabUsers'

Consultez la création d’OU et les paramètres de création d’utilisateur. Si la stratégie de mot de passe rejette la valeur saisie, vérifiez l'erreur et l'état Enabled du compte ; ne présumez pas que la création a réussi.

Déplacez les objets ordinateurs et testez l’utilisateur standard

Dans la console AD, utilisez Déplacer pour placer CLIENT1 dans Lab\Workstations et FS1 dans Lab\Servers, si FS1 existe déjà et n'est pas un contrôleur de domaine. Vérifiez ensuite les emplacements des objets et l'état du compte :

Get-ADComputer -Identity 'CLIENT1' | Select-Object Name,DistinguishedName
Get-ADComputer -Identity 'FS1' | Select-Object Name,DistinguishedName
Get-ADUser -Identity 'labuser1' -Properties Enabled | Select-Object SamAccountName,Enabled,DistinguishedName

Sur CLIENT1, fermez la session, connectez-vous avec labuser1@ad.example.test, changez le mot de passe initial si demandé et vérifiez whoami. Ce groupe n'a pas encore reçu de droits sur les fichiers : un refus d'accès à un partage ne signifie donc pas, à lui seul, que la création du groupe a échoué.

Les paramètres de stratégie visant les utilisateurs et ceux visant les ordinateurs dépendent de l'emplacement de leurs objets respectifs. Déplacer un utilisateur ne déplace pas son ordinateur.

Vérifiez les changements d'appartenance avant de supprimer des objets

Une session existante peut conserver un ancien jeton d'accès. Après une déconnexion et une nouvelle connexion, comparez l'appartenance dans AD avec le résultat de whoami /groups. Avant de renommer ou de supprimer des comptes et groupes, examinez les autorisations des applications et fichiers qui en dépendent.

Lors du nettoyage, déplacez les objets à conserver vers les emplacements appropriés et examinez les liens de stratégie et les délégations. La protection contre la suppression accidentelle est intentionnelle. Ne la retirez que pour une UO précisément choisie après vérification, sans supprimer récursivement tout l'arbre Lab.