Le blog technique

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.

Lors d’audits Active Directory, la recherche d’objets via PowerShell est une opération critique.
Les cmdlets telles que Get-ADUser, Get-ADComputer ou Get-ADObject proposent le paramètre -Filter, souvent suffisant pour des requêtes simples. Cependant, dès que les critères se complexifient, ce mode de filtrage montre rapidement ses limites.

Dans plusieurs scripts d’audit, certaines recherches retournaient un volume excessif d’objets, tandis que d’autres ne renvoyaient aucun résultat sans erreur explicite. Ces comportements étaient dus à des filtres trop permissifs, mal interprétés, ou difficiles à maintenir lorsque plusieurs conditions entraient en jeu.

L’utilisation des filtres LDAP via le paramètre -LDAPFilter s’est alors révélée être une solution plus robuste. Les filtres LDAP sont interprétés nativement par Active Directory, ce qui garantit une meilleure précision et des performances supérieures, notamment dans des environnements de grande taille.

Exemples concrets

Get-ADUser -LDAPFilter "(&(objectClass=user)(employeeID=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"

Cela retourne uniquement les comptes utilisateurs activés disposant d’un EmployeeID.

Get-ADUser -LDAPFilter "(&(objectClass=user)(servicePrincipalName=*))"

Très efficace pour détecter les comptes exposés à des risques de type Kerberoasting.