Dans de nombreux scripts PowerShell Active Directory, le DistinguishedName (DN) est utilisé comme point d’entrée pour cibler des objets précis : utilisateurs, ordinateurs ou unités d’organisation. Il est courant de récupérer un DN une première fois, puis de le réutiliser tel quel dans des scripts automatisés ou des tâches planifiées.

Ce fonctionnement semble fiable, mais il devient rapidement fragile dans des environnements Active Directory vivants, où les OU sont régulièrement déplacées, renommées ou restructurées.

Problème rencontré

Plusieurs scripts d’audit ou d’administration ne retournaient aucun résultat, ou échouaient partiellement sans générer d’erreur explicite.
Dans certains cas, les mêmes scripts fonctionnaient parfaitement sur un domaine, mais pas sur un autre.

Le comportement était trompeur : aucune exception PowerShell, aucun message d’erreur AD, simplement zéro objet retourné.

Analyse

Après investigation, les causes les plus fréquentes étaient :

• un DistinguishedName mal formé (virgule manquante, casse incorrecte)
• une OU déplacée ou renommée
• un DN codé en dur devenu obsolète
• une OU supprimée puis recréée (DN identique visuellement, mais objet différent)
• une différence de structure entre environnements (prod / préprod)

Active Directory ne valide pas toujours explicitement un DN incorrect : la requête est acceptée, mais ne retourne aucun résultat, ce qui complique fortement le diagnostic.

Exemples concrets

Get-ADUser -SearchBase "OU=Users,OU=IT,DC=corp,DC=contoso,DC=com" -Filter *

Échoue silencieusement si l’OU est déplacée ou renommée car le DN est codé en dur.

$OU = Get-ADOrganizationalUnit -LDAPFilter "(ou=Users)" -SearchBase "DC=corp,DC=contoso,DC=com"
Get-ADUser -SearchBase $OU.DistinguishedName -Filter *

Le script s’adapte automatiquement à l’arborescence réelle car le DN est dynamique.