6.2 : Le module ActiveDirectory : automatiser l’AD

Sophie vous emmène devant la console du contrôleur de domaine : « Tout ce qu’on a fait jusqu’ici — comptes locaux, services — ne concernait qu’un seul poste à la fois. Avec l’Active Directory, on parle de milliers de comptes, sur toute l’entreprise. C’est là que PowerShell devient vraiment indispensable : personne ne gère 3000 comptes à la main. »

Installer le module

Comme évoqué en fin de leçon 6.1, le module ActiveDirectory ne s’installe pas via Install-Module. Sur un poste Windows client (Windows 10/11), il fait partie des RSAT (Remote Server Administration Tools) :

Get-WindowsCapability -Name "Rsat.ActiveDirectory*" -Online
Add-WindowsCapability -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0" -Online

Sur un serveur Windows Server, le module est installé en même temps que le rôle AD DS, ou via la fonctionnalité RSAT-AD-PowerShell :

Install-WindowsFeature -Name RSAT-AD-PowerShell

Source officielle : la documentation Microsoft sur l’installation des RSAT détaille les procédures exactes selon la version de Windows utilisée, qui évoluent régulièrement d’une version à l’autre.

Une fois installé, on importe le module comme n’importe quel autre :

Import-Module ActiveDirectory

Rechercher des comptes existants

Get-ADUser suit exactement la même logique que Get-LocalUser vue en 4.4, mais interroge l’annuaire de tout le domaine plutôt qu’un seul poste :

Get-ADUser -Filter { Name -eq "Julie Dupont" }

Pour récupérer davantage de propriétés (par défaut, Get-ADUser n’en renvoie que quelques-unes) :

Get-ADUser -Filter { Department -eq "Comptabilite" } -Properties EmailAddress, Title

Créer un compte dans l’Active Directory

ew-ADUser reprend la logique de New-LocalUser (4.4), avec des paramètres propres à l’annuaire d’entreprise, notamment l’unité d’organisation (OU) où placer le compte :

$motDePasse = ConvertTo-SecureString "Nordika2026!" -AsPlainText -Force

New-ADUser -Name "Julie Dupont" `
           -GivenName "Julie" `
           -Surname "Dupont" `
           -SamAccountName "j.dupont" `
           -UserPrincipalName "[email protected]" `
           -Path "OU=Comptabilite,OU=Utilisateurs,DC=nordika,DC=local" `
           -AccountPassword $motDePasse `
           -Enabled $true

Le paramètre -Path désigne l’OU cible avec une syntaxe LDAP (Distinguished Name) : on lit de droite à gauche, du domaine (DC=nordika,DC=local) vers l’OU la plus précise (OU=Comptabilite).

Retour d’expérience terrain : l’erreur la plus fréquente sur New-ADUser concerne justement ce chemin -Path : une seule virgule mal placée ou une OU mal orthographiée renvoie une erreur peu explicite (« chemin introuvable »). Avant tout script de création en masse, validez toujours le chemin exact avec Get-ADOrganizationalUnit -Filter * pour lister les OU réellement disponibles sur le domaine.

Gérer les groupes de sécurité

Comme pour les groupes locaux (4.4), on ajoute un utilisateur à un groupe AD :

Add-ADGroupMember -Identity "Comptabilite-Lecture" -Members "j.dupont"

Lister les membres d’un groupe :

Get-ADGroupMember -Identity "Comptabilite-Lecture"

Modifier ou désactiver un compte

Set-ADUser -Identity "j.dupont" -Title "Comptable Senior"
Disable-ADAccount -Identity "j.dupont"

Exactement comme recommandé en 4.4 pour les comptes locaux, Disable-ADAccount reste préférable à Remove-ADUser dans la plupart des cas : le compte est bloqué, mais reste disponible pour un audit ou une restauration.

Un exemple concret Nordika : automatiser enfin le ticket de la rentrée

En combinant Import-Csv (vu au TP de la section 5) et New-ADUser, le vrai ticket évoqué dès l’introduction de cette formation devient enfin réalisable à grande échelle :

Import-Module ActiveDirectory

$comptes = Import-Csv -Path ".\comptes.csv"
$motDePasse = ConvertTo-SecureString "Nordika2026!" -AsPlainText -Force

foreach ($ligne in $comptes) {
    $samAccountName = "$($ligne.Prenom.Substring(0,1)).$($ligne.Nom)".ToLower()

    try {
        New-ADUser -Name "$($ligne.Prenom) $($ligne.Nom)" `
                   -GivenName $ligne.Prenom `
                   -Surname $ligne.Nom `
                   -SamAccountName $samAccountName `
                   -UserPrincipalName "[email protected]" `
                   -Path "OU=$($ligne.Service),OU=Utilisateurs,DC=nordika,DC=local" `
                   -AccountPassword $motDePasse `
                   -Enabled $true `
                   -ErrorAction Stop

        Write-Output "$samAccountName créé avec succès"
    } catch {
        Write-Warning "Échec pour $samAccountName : $($_.Exception.Message)"
    }
}

On retrouve ici, presque à l’identique, le squelette du TP de la section 5 (import CSV, boucle, try/catch) — seule la cmdlet de création change, passant de New-LocalUser à New-ADUser. C’est précisément l’intérêt d’avoir posé ces bases solides en section 5 : elles se transposent directement à l’échelle de toute l’entreprise.

Source officielle : la documentation Microsoft about_ActiveDirectory_Filter détaille la syntaxe complète des filtres AD, sensiblement différente des filtres Where-Object vus en section 2 — un point de confusion fréquent à connaître avant d’écrire des filtres complexes sur l’annuaire.

Dans la prochaine leçon, on termine cette section modules avec un objectif différent : créer son propre module réutilisable, pour empaqueter proprement les fonctions Nordika déjà écrites.

Sécuriser l’usage de PowerShell sur l’Active Directory

Tout ce qu’on vient de voir dans cette leçon donne un pouvoir considérable : créer, modifier ou désactiver n’importe quel compte du domaine en quelques lignes. Sophie insiste particulièrement sur ce point avec chaque nouvel arrivant du service IT : « Un script AD mal maîtrisé peut faire plus de dégâts en 10 secondes qu’une erreur de clic n’en ferait en une journée. »

Quelques principes essentiels à respecter dès qu’on manipule l’AD en environnement de production :

Ne jamais utiliser un compte Domain Admin pour des scripts courants. Un compte disposant des droits d’administration complets du domaine ne devrait servir qu’à des opérations ponctuelles et supervisées, jamais à l’exécution automatisée ou régulière d’un script. Le principe du moindre privilège s’applique ici directement : un compte de service dédié, avec des droits délégués uniquement sur les OU concernées, limite considérablement l’impact d’un script buggé ou d’un identifiant compromis.

Déléguer les droits plutôt qu’accorder l’administration complète. L’AD permet une délégation fine via la console dsa.msc ou le module PowerShell lui-même (Get-Acl/Set-Acl sur un objet AD) : un compte de service peut par exemple n’avoir le droit de créer des comptes que dans l’OU Comptabilite, sans aucun accès au reste de l’annuaire.

Toujours tester en environnement de non-production d’abord. Un script de création ou de modification en masse, comme celui vu plus haut, mérite un premier passage sur un domaine de test ou un petit lot d’OU sans impact, avant tout déploiement sur l’annuaire réel de l’entreprise.

Journaliser systématiquement les actions d’un script touchant à l’AD. Contrairement à une action manuelle dans la console, un script exécuté seul (notamment planifié, comme on le verra en section 8) ne laisse aucune trace visible sans un logging explicite. Un simple Write-Output redirigé vers un fichier, ou l’utilisation de Start-Transcript (vue plus en détail en section 9), permet de conserver une preuve de ce qui a réellement été exécuté, et quand.

Ne jamais stocker un mot de passe en clair dans un script, comme fait volontairement dans l’exemple pédagogique plus haut ("Nordika2026!" en dur). En production, ce mot de passe devrait provenir d’un coffre-fort de secrets, sujet qu’on détaille en profondeur en section 9 avec SecretManagement.

Retour d’expérience terrain : l’incident le plus fréquent que j’ai pu constater ou entendre relater dans des environnements d’entreprise n’est presque jamais une faille technique sophistiquée, mais un script de bonne foi, exécuté avec des droits trop larges, sur le mauvais périmètre, sans confirmation préalable. Le réflexe -WhatIf (vu en section 4) fonctionne aussi sur la plupart des cmdlets AD comme Remove-ADUser ou Disable-ADAccount — un filet de sécurité simple, à ne jamais négliger avant une action en masse sur l’annuaire.

Automatiser l’AD avec PowerShell, c’est donner à l’atelier Nordika une machine capable de reconfigurer toute l’usine en quelques secondes. C’est extrêmement puissant — à condition que seules les bonnes personnes, avec les bons droits, puissent l’actionner.