Le blog technique

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.

Dans les scripts Active Directory, la récupération d’informations sur les comptes utilisateurs repose très souvent sur la cmdlet Get-ADUser. Simple à utiliser et bien intégrée aux besoins courants, elle est généralement le premier choix pour interroger des objets de type utilisateur. Cependant, dans certains scénarios d’audit ou d’automatisation avancée, cette cmdlet peut rapidement montrer ses limites.

Get-ADUser est une cmdlet spécialisée, conçue exclusivement pour les objets strictement typés User. Elle repose sur un schéma d’attributs prédéfini et masque une partie de la complexité du modèle Active Directory. Cette abstraction facilite l’écriture de scripts simples, mais elle restreint l’accès à certains attributs spécifiques ou étendus, notamment ceux issus de schémas personnalisés ou de configurations particulières.

Lors de travaux d’audit, il est possible de constater que certains objets ne sont pas remontés ou que certains attributs ne sont tout simplement pas accessibles via Get-ADUser. C’est notamment le cas pour des objets hybrides, des comptes atypiques, ou lorsque des filtres LDAP complexes sont nécessaires pour affiner les résultats.

À l’inverse, Get-ADObject permet d’interroger n’importe quel objet Active Directory, sans restriction de type. Cette cmdlet s’appuie directement sur des filtres LDAP et offre un accès complet aux attributs du schéma, y compris les attributs personnalisés ou rarement utilisés. Elle nécessite en revanche une meilleure compréhension de la structure Active Directory et du langage LDAP.

Dans les scripts nécessitant davantage de précision et de flexibilité, l’utilisation de Get-ADObject avec un paramètre -LDAPFilter s’avère souvent plus adaptée. Elle permet de cibler précisément les objets recherchés, qu’il s’agisse d’utilisateurs, de contacts, d’objets système ou de comptes non standards.

Le choix entre Get-ADUser et Get-ADObject dépend donc du contexte. Pour des scripts simples et lisibles, Get-ADUser reste parfaitement appropriée. En revanche, pour des scripts d’audit, de reporting ou d’automatisation avancée, Get-ADObject offre une souplesse indispensable et permet de concevoir des scripts plus génériques, robustes et réutilisables.