Recensement des enfants directs OU AD : vérifier avant de restructurer

Ce qu’établit un recensement des enfants directs OU AD

Un recensement des enfants directs OU AD consigne les objets situés immédiatement sous une unité d’organisation donnée. Avant une restructuration, utilisez-le pour répondre à une question précise : que contient cette OU à ce niveau, dans la vue de l’annuaire que nous avons réellement lue ? Conservez un inventaire distinct de la hiérarchie sous-jacente. Un décompte des enfants directs aide à planifier, mais un compteur apparemment vide ne doit jamais déclencher automatiquement une suppression.

Ce guide a été relu le 4 octobre 2026 à partir de Microsoft Learn et de la révision du collecteur identifiée ci-dessous. Il propose une procédure de rapprochement aux administrateurs qui examinent un inventaire d’OU. Les commandes PowerShell sont des exemples documentaires destinés au lecteur, adaptés de la syntaxe documentée des paramètres ; elles n’ont pas été exécutées sur un domaine AD pour cet article. Aucune collecte réussie, OU de production vide ou modification achevée n’est revendiquée.

Le problème pratique tient à l’écart entre le libellé d’un compteur et sa population. Un rapport peut afficher Users, Computers, Groups et OUs alors que le lecteur suppose qu’il décrit tous les objets sous l’OU. Il peut aussi omettre des objets en raison de limites de collecte, d’exclusions ou d’une comparaison du DN parent. Conservez ces limites avant d’utiliser le rapport dans une demande de changement.

Fonctionnement : séparer les décomptes sur un niveau de la hiérarchie

La référence Get-ADObject de Microsoft distingue OneLevel, qui recherche les enfants immédiats, de Subtree, qui inclut la base et les descendants. SearchBase définit le chemin cible et Server sélectionne l’instance d’annuaire. Précisez les deux pour produire des éléments de preuve.

Constituez deux dossiers pour la même cible : un inventaire des enfants directs pour la population locale et un inventaire du sous-arbre pour les dépendances plus profondes dans la hiérarchie. Indiquez explicitement leurs périmètres. Ne comparez pas la somme des compteurs de classes d’enfants directs à un total de sous-arbre sans qualification. Une OU contenant une autre OU peut compter peu d’identités directes alors que la hiérarchie subordonnée contient les objets importants pour le changement.

Pour chaque inventaire, conservez les identifiants d’objets, les DN d’origine, la classe, le contexte de collecte et l’état d’achèvement. Gardez la liste brute des objets à côté de chaque décompte récapitulatif pour pouvoir examiner un écart sans deviner quels objets y ont contribué. Une liste d’objets permet aussi de distinguer une classe inattendue d’une relation parentale inattendue.

Définir le sens des libellés de classes

Traitez Users, Computers, Groups et OUs comme quatre populations du collecteur, sans y voir la garantie que toutes les classes de l’annuaire ont été lues. Définissez les requêtes indépendantes avant de les comparer. Consignez séparément les autres classes renvoyées ; ne les intégrez pas discrètement à Users et ne les ignorez pas parce que le tableau de bord n’a pas de compteur correspondant.

Le filtre par défaut de la population d’utilisateurs LDAP examinée inclut une branche de comptes de service administrés de groupe. La requête d’utilisateurs de catégorie person ci-dessous peut donc différer du compartiment Users du collecteur même si les deux lectures aboutissent. Comparez les définitions réelles des filtres et les identifiants d’objets renvoyés. Gardez les sous-classes de comptes de service et les autres classes sans correspondance visibles dans le dossier de rapprochement, au lieu de forcer l’égalité numérique.

Notre guide des conteneurs par défaut et du périmètre des stratégies de groupe explique pourquoi les destinations par défaut et le périmètre de stratégie prévu nécessitent un examen distinct du placement. Son exemple OneLevel inventorie les ordinateurs du conteneur Computers par défaut. Il ne recense pas les quatre populations d’une OU, ne couvre pas toutes les classes et ne résout pas le problème des DN échappés traité ici.

Détection : lire les objets avant de comparer les compteurs

1. Établir le contexte des requêtes

Sélectionnez l’OU approuvée et un serveur d’annuaire explicite. Consignez le contexte de lecture de l’opérateur, les heures de début et de fin, la base de recherche, le périmètre, le filtre de classe et les erreurs éventuelles. Utilisez un poste d’administration autorisé équipé du module AD PowerShell. Le DN d’OU ci-dessous figure dans l’exemple 5 de la référence Get-ADObject ; le nom du serveur est un FQDN fictif servant de valeur de remplacement. Remplacez les deux par la cible examinée.

Les exemples suivants adaptent les paramètres documentés Filter, LDAPFilter, SearchBase, SearchScope, Server et Properties de Get-ADObject. Ils demandent des identifiants pour le rapprochement. Enregistrez les objets renvoyés et le résultat de l’opération dans votre procédure d’administration avant de calculer un récapitulatif.

Lisez d’abord la population directe sans restriction de classe :

Get-ADObject -Filter * -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Utilisez cette liste pour découvrir les classes que les quatre compteurs ne décrivent pas. L’inventaire reste limité par la vue sélectionnée et le contexte de lecture. S’il échoue ou s’arrête prématurément, conservez ce résultat ; les objets déjà affichés ne prouvent pas que le recensement est complet.

2. Garder les requêtes de classes séparées

Ces exemples destinés au lecteur définissent des populations d’examen distinctes ; ils ne reproduisent pas tous les filtres du collecteur. Le premier combine objectClass=user et objectCategory=person, conformément aux instructions de Microsoft sur la recherche d’utilisateurs. Un filtre portant uniquement sur la classe user correspond aussi aux ordinateurs, car la classe computer dérive de user :

Get-ADObject -LDAPFilter '(&(objectClass=user)(objectCategory=person))' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "computer"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "group"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Get-ADObject -Filter 'ObjectClass -eq "organizationalUnit"' -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope OneLevel -Server 'dc01.fabrikam.com' -Properties objectGUID

Gardez les quatre sorties identifiables individuellement. Consignez l’achèvement de chaque requête et comparez son ensemble d’objets à la liste OneLevel sans restriction. Si une autre classe apparaît, ajoutez une population d’examen avec un libellé distinct. Lorsqu’un compartiment du collecteur utilise un filtre plus large, documentez la population supplémentaire avant de rapprocher son décompte.

3. Lire le sous-arbre comme une preuve différente

Utilisez une opération distincte pour la hiérarchie :

Get-ADObject -Filter * -SearchBase 'OU=Accounting,DC=Fabrikam,DC=com' -SearchScope Subtree -Server 'dc01.fabrikam.com' -Properties objectGUID

Étiquetez cette sortie Subtree et distinguez l’OU de base des objets situés sous elle. Examinez les OU subordonnées et leur contenu avec leurs responsables. N’ajoutez pas ce total aux compteurs d’enfants directs et ne le présentez pas comme une seconde mesure de la même population.

4. Rapprocher les identifiants et les DN échappés

Learn documente objectGUID comme un identifiant accepté par Get-ADObject. Utilisez-le comme clé de comparaison dans les inventaires indépendants et conservez le DN comme preuve d’emplacement. Si la charge utile du collecteur n’a pas de GUID, résolvez son DN enregistré dans le même contexte et conservez le lien ; n’inventez pas d’identifiant et ne faites pas de correspondance sur le seul nom affiché.

La référence des noms distinctifs de Microsoft explique que les RDN sont séparés par des virgules et qu’une virgule dans une valeur d’attribut doit être échappée. Une virgule brute ne suffit donc pas à déterminer où un nom se termine et où son parent commence.

Par exemple, Learn fournit ce DN avec une virgule échappée dans le RDN de l’OU :

CN=Litware,OU=Docs\, Adatum,DC=Fabrikam,DC=COM

Privilégiez le résultat OneLevel de l’annuaire pour établir la parenté immédiate. Si un export doit être traité localement, utilisez un analyseur de DN qui gère les échappements et conservez la chaîne d’origine. Ne découpez pas à chaque virgule et ne supprimez pas les barres obliques inverses avant de déterminer la parenté.

Rapprocher le recensement avant la restructuration (Remediation)

1. Qualifier chaque observation

Utilisez le dossier de rapprochement pour déterminer ce qui est établi et ce qui reste ouvert. Un écart justifie d’examiner le périmètre, les filtres, les identifiants ou la collecte, plutôt que de modifier les objets jusqu’à ce que les décomptes concordent.

Associez cette classification à l’OU et à la classe précises. Un libellé de ligne entière comme « vide » fait perdre la distinction entre un zéro de classe vérifié et une lecture de classe manquante. Si différentes requêtes se sont achevées à des instants différents, conservez cette différence au lieu de les présenter comme un instantané simultané.

2. Expliquer les différences avant de modifier la hiérarchie

Comparez d’abord les objets individuels, puis les totaux. Consignez si chaque différence provient d’une autre classe, d’un descendant plus profond, d’une exclusion, d’un filtre, d’une collecte incomplète ou d’une correspondance parentale non résolue. Laissez les différences inexpliquées ouvertes, avec un examinateur responsable et les preuves nécessaires à leur résolution.

Utilisez le même serveur et le même contexte cible pour le premier rapprochement. Si l’examen inclut un autre serveur, étiquetez son inventaire séparément. Une différence entre les vues doit être étudiée ; cette procédure ne permet pas de deviner un résultat de réplication ni de considérer un décompte commode comme faisant autorité.

Documentez les exclusions du collecteur et les limites de collecte éventuelles à côté des lectures indépendantes. Gardez le recensement administratif sans restriction séparé d’un sous-ensemble volontairement aligné sur les entrées du collecteur. Un objet exclu reste important pour la restructuration même s’il ne contribue pas à un compteur filtré.

3. Conserver la responsabilité et les protections contre la suppression

Remettez au responsable le dossier au niveau des objets, l’examen du sous-arbre, les différences non résolues et le périmètre proposé. Obtenez une décision concernant la cible exacte et ses dépendances. Un nom d’OU, un faible décompte ou un champ vide du tableau de bord n’indique pas qui peut approuver un déplacement ou un nettoyage.

Suivez le guide complémentaire sur l’examen indépendant des permissions et la décision du responsable avant le nettoyage d’une OU. Il traite des protections contre la suppression et des exceptions délimitées. Conservez cet examen dans le processus de changement ; ce recensement n’évalue pas les permissions concernées et n’autorise pas le retrait de la protection.

Avant d’approuver la restructuration, identifiez les conséquences prévues en matière de stratégie et d’administration pour les objets concernés. Gardez le placement dans les conteneurs par défaut et le périmètre des GPO dans l’examen du placement, et les protections contre la suppression dans l’examen complémentaire des permissions. Le recensement fournit la population d’objets dont dépendent ces décisions.

4. Vérifier le résultat approuvé

Après un changement autorisé, répétez les lectures OneLevel et Subtree pertinentes dans le contexte cible enregistré. Rapprochez les objets conservés par identifiant et consignez leurs emplacements actuels. Gardez la décision du responsable et le résultat réel de l’opération à côté des preuves avant et après.

Clôturez la tâche d’inventaire lorsque les populations convenues et les incertitudes restantes sont documentées. Clôturez la tâche de changement selon ses propres critères de résultat, notamment l’examen complémentaire des protections. Un décompte paraissant plus propre ne suffit pas à établir que les dépendances, le périmètre des stratégies et la protection des objets conservés ont été traités.

Comment EtcSec détecte cela

Cette section décrit uniquement INFO_DOMAIN_OU_INVENTORY, examiné dans le commit afca1b9f7bba6f076d6a6493371486071001452b d’etc-collector. Le détecteur concerné est public/internal/audit/detectors/ad/permissions/organization/ou-inventory.go:31.

Sa méthode Detect() émet un résultat Info avec Count=1 pour chaque OU collectée. Ce décompte désigne une entrée d’inventaire, pas le nombre d’enfants ni un verdict de vulnérabilité. Elle ne renvoie aucun résultat lorsque l’entrée d’OU est vide. Les détails des entités concernées ne sont renseignés que si IncludeDetails est activé ; des détails absents ne prouvent pas l’absence d’enfants.

La méthode GetOUs du fournisseur LDAP, à public/internal/providers/ldap/client.go:946, lit les unités d’organisation à travers son utilitaire de recherche de sous-arbre. Une collecte des OU dans le sous-arbre ne transforme pas les compteurs d’enfants émis en décomptes de descendants et ne prouve pas une exhaustivité universelle.

Dans public/internal/audit/gpo_policy.go:365–436, OUEntity construit ChildCounts à partir des tableaux Users, Computers, Groups et OUs fournis. L’utilitaire compte uniquement les enfants immédiats. Les exclusions d’actifs appliquées avant la détection affectent ces populations ; les autres classes de l’annuaire ne constituent pas un cinquième compteur de tous les objets. Le décompte doit être interprété en fonction de ce qui a réellement été collecté.

Le test du parent vérifie un suffixe d’OU sans tenir compte de la casse, puis rejette une partie initiale contenant une virgule quelconque. Déduction statique : une virgule échappée dans le RDN initial peut provoquer l’omission d’un véritable enfant direct. Cela découle du prédicat de chaîne examiné et des règles documentées d’échappement des DN ; ce phénomène n’a pas été démontré ici par l’exécution d’un test sur un domaine.

Enfin, OUEntity initialise Delegations avec un tableau vide de remplacement, car le câblage des délégations DACL d’OU n’est pas renseigné sur ce chemin. Il n’apporte aucune preuve d’absence de droits délégués. Utilisez l’inventaire pour sélectionner et rapprocher les OU ; établissez leur contenu, les permissions et le résultat approuvé de la restructuration au moyen des preuves distinctes décrites ci-dessus.