Les bases de la Terminologie AD

Introduction

« Objet », « branche », « forêt ». Si vous n’avez jamais touché à un Active Directory de votre vie, vous pourriez imaginer une randonnée champêtre, ou un atelier de menuiserie. Pourtant, derrière ces mots simples se cache un système sur lequel repose une part considérable de la mécanique interne des organisations modernes. Un univers où la hiérarchie n’est pas qu’organique, où chaque structure porte en elle un soupçon d’histoire, de compromis et parfois, disons-le, de négligence affective.

Il faut dire que l’Active Directory, tel qu’il est souvent hérité, a parfois des airs de grenier familial. On y retrouve des unités d’organisation figées depuis 2011, des comptes de service aux noms qui relèvent du mystique (générés probablement sous l’effet d’un café mal dosé), et des GPO dont l’origine se perd dans les brumes du temps. Et comme dans tout bon grenier, tout le monde sait qu’il ne faut surtout rien toucher. Au risque de mettre quelqu’un en rogne.

Ce glossaire, que je vous propose de parcourir, n’a pas vocation à faire de vous un expert de l’annuaire LDAP. Il ambitionne plutôt de mettre des mots – les bons cette fois – sur des concepts que l’on utilise parfois machinalement, sans toujours en saisir la portée. Comprendre le langage de l’AD, c’est aussi mieux comprendre l’AD lui-même. Et par ricochet, un peu de l’organisation qui le porte.

Car au-delà de sa dimension technique, Active Directory est un révélateur. De la gouvernance implicite. Des choix d’hier qui pèsent sur les risques d’aujourd’hui. Et pour celles et ceux qui œuvrent dans la cybersécurité, c’est souvent là que commence – ou se perd – une posture défensive cohérente.

C’est aussi, très concrètement, l’endroit où l’on va chercher des preuves lors d’un audit ISO 27001. Qui a accès à quoi ? Depuis quand ? Qui a modifié cette délégation ? Pourquoi tel groupe est membre d’un autre ? Autant de questions qui trouvent leurs réponses – ou pas – dans les replis d’un AD bien (ou mal) entretenu. On y lit des intentions, des négligences, parfois des bricolages d’urgence un vendredi soir. Et c’est exactement pour cela qu’il mérite d’être compris avant d’être jugé.

Voici donc la table des matières que l’on va explorer aujourd’hui.

Table des matières

Terminologie

Object

Élément fondamental d’Active Directory représentant une ressource identifiable.
Peut désigner un utilisateur, un ordinateur, une imprimante, un groupe, une unité d’organisation (OU), ou tout autre composant géré dans le domaine.
Chaque objet possède un identifiant unique (GUID) et un ensemble d’attributs définis par sa classe.

Attributs

Propriété ou caractéristique d’un objet dans Active Directory.
Chaque objet possède un ensemble d’attributs définis par son type (ou « classe »), comme givenName, surName, ou memberOf, qui contient la liste des groupes auxquels appartient l’objet.
Les attributs sont stockés dans le schéma AD et peuvent être simples (une seule valeur) ou multi-valués.

Schéma

Le schéma définit la structure des objets dans Active Directory, de la même manière qu’une classe définit un objet en programmation orientée objet.

Il précise :

Les types d’objets autorisés (ex. : utilisateur, groupe, ordinateur)
Les attributs que chaque type d’objet peut ou doit contenir
Les règles de relations entre objets

On peut le voir comme une bibliothèque de « moules » prédéfinis, permettant de créer des objets en remplissant simplement leurs attributs.

Le schéma peut être étendu (avec prudence) pour ajouter de nouveaux types ou attributs personnalisés.

Domaine

Unité logique de base dans Active Directory, qui regroupe et organise un ensemble d’objets (utilisateurs, ordinateurs, groupes, etc.).

Un domaine partage une base de données commune, une politique de sécurité, et une configuration centralisée.

On peut l’imaginer comme une « ville » dans un pays (la forêt), avec ses habitants (objets) et ses propres règles (politiques de groupe, contrôleurs de domaine).

Chaque domaine est identifié par un nom DNS (ex : tarek.guru).

Forêt

Structure hiérarchique la plus haute d’Active Directory.

Une forêt est un ensemble d’un ou plusieurs domaines qui partagent un schéma et un catalogue global commun.

Elle représente la racine absolue de l’annuaire : rien n’est « au-dessus » d’elle.

Une forêt contient toujours au moins un domaine racine.
Plusieurs forêts peuvent coexister sur un même annuaire, mais elles restent isolées par défaut (pas de confiance implicite entre elles, on parlera de confiance dans un prochain article).
Toutes les relations de confiance entre domaines inter-forêts doivent être créées manuellement.

Pense à la forêt comme un « pays » contenant une ou plusieurs « villes » (domaines) partageant les mêmes lois fondamentales (schéma, configuration globale).

Arbre

Un arbre est un ensemble de domaines AD organisés de manière hiérarchique et liés par des relations de confiance automatiques et bidirectionnelles.

Tous les domaines d’un même arbre partagent un espace de noms DNS contigu (ex. : TAREK.GURU, EUROPE.TAREK.GURU, etc.).

Un ou plusieurs arbres peuvent exister dans une forêt, chacun avec sa propre hiérarchie de domaines.

Un domaine doit ABSOLUMENT doit faire partie d’un arbre.

Un arbre doit ABSOLUMENT faire partie d’une forêt.

Branche et Feuille

Dans la structure hiérarchique d’Active Directory (vue comme un arbre) :

Une branche est un nœud intermédiaire, représentant un objet qui contient d’autres objets (ex. : une Unité d’Organisation – OU).
Une feuille est un objet final, qui ne contient rien d’autre (ex. : un utilisateur, une imprimante, un ordinateur).

Autrement dit, c’est un chemin (branche) ou la fin d’un chemin (feuille) dans l’arborescence AD.

Global Unique Identifier (GUID)

Identifiant unique de 128 bits attribué automatiquement à chaque objet lors de sa création dans Active Directory.

Il reste constant tout au long de la vie de l’objet, même si son nom, son chemin (DN) ou d’autres attributs changent.

Le GUID est très utile pour effectuer des recherches fiables, car il garantit une référence unique, même si l’objet est déplacé ou renommé.

C’est l’équivalent d’un identifiant système immuable.

Principaux de sécurité

Toute entité pouvant être authentifiée par Active Directory et à laquelle on peut attribuer des droits ou des permissions.
Cela inclut :

Les utilisateurs
Les ordinateurs (workstations, serveurs)
Les groupes
Les comptes de service (ex. : svc-...)
Et parfois des processus ou threads via des comptes techniques

Chaque principal de sécurité possède un SID (Security Identifier) unique, utilisé pour le contrôle d’accès (ACL) et les audits.

Security Identifier (SID)

Toute entité pouvant être authentifiée par Active Directory et à laquelle on peut attribuer des droits ou des permissions (via des ACL). Donc forcément des principaux de sécurité qu’on a vu plus haut.

Cela inclut :

les utilisateurs
les ordinateurs (workstations, serveurs)
les groupes
les comptes de service (ex. : svc-…)
éventuellement des processus ou threads, via des comptes techniques

Chaque principal de sécurité est identifié de manière unique par un SID, utilisé pour le contrôle d’accès, les audits, et la gestion des permissions.

Distinguished Name (DN)

Chemin absolu qui identifie de manière unique un objet dans la hiérarchie Active Directory.

Il indique la position exacte de l’objet depuis la racine de l’annuaire (le domaine).

Exemple :
cn=tarek.mahfoudh, ou=hr, ou=employees, dc=tarek, dc=guru

Dans cet exemple, l’objet est un utilisateur situé dans l’unité d’organisation « hr », elle-même dans « employees », au sein du domaine « tarek.guru ».

Le DN est souvent utilisé dans les scripts LDAP et les requêtes ciblées sur l’annuaire.

Relative Distinguished Name (RDN)

Partie du DN qui identifie un objet par rapport à son parent direct dans la hiérarchie Active Directory.

C’est le segment le plus proche de l’objet lui-même.

Exemple :
Dans le DN cn=tarek.mahfoudh, ou=hr, ou=employees, dc=tarek, dc=guru
le RDN est cn=tarek.mahfoudh, car il identifie l’objet par rapport à l’OU « hr », son conteneur immédiat.

Chaque niveau de la hiérarchie a son propre RDN. Le DN complet est la concaténation de tous les RDN jusqu’à la racine.

sAMAccountName

Nom de connexion d’un utilisateur (ou d’un autre principal de sécurité) dans un environnement Active Directory compatible avec les anciennes versions de Windows (NT4).

C’est un identifiant court, unique dans le domaine.

Exemple :
Pour l’objet cn=tarek.mahfoudh, ou=hr, ou=employees, dc=tarek, dc=guru
le sAMAccountName est tarek.mahfoudh, et peut être utilisé pour se connecter sous la forme DOMAINE\tarek.mahfoudh.

Il est limité à 20 caractères pour des raisons d’héritage.

userPrincipalName

Identifiant de connexion au format adresse e-mail, utilisé dans les environnements modernes (Kerberos, Azure AD, etc.).

Formé comme suit : nom_utilisateur@domaine_DNS

Exemple :
Pour l’objet cn=tarek.mahfoudh, ou=hr, ou=employees, dc=tarek, dc=guru
le UPN est tarek.mahfoudh@tarek.guru

Le UPN est souvent préféré au sAMAccountName car il est plus universel et compatible avec les systèmes fédérés ou cloud.

Rôles FSMO

Dans une architecture Active Directory avec plusieurs contrôleurs de domaine, certains rôles critiques ne peuvent être assurés que par un seul DC à la fois pour éviter les conflits.

Ces rôles sont appelés FSMO (Flexible Single Master Operations).

Ils permettent de centraliser certaines opérations sensibles (comme la création d’objets, la gestion des schémas, etc.) tout en maintenant la souplesse d’un système distribué.

On détaillera les cinq rôles FSMO dans un autre article mais voici un apreçu :

Roles	Description
`Schema Master`	Gère la lecture et l’écriture du schéma Active Directory, qui définit la structure de tous les objets et attributs dans l’annuaire. Ce rôle est requis pour toute modification du schéma, comme l’ajout d’attributs personnalisés ou l’extension pour certaines applications (Exchange, SCCM…). Il n’y a qu’un seul Schema Master par forêt.
`Domain Naming Master`	Responsable de la gestion des noms de domaine au sein de la forêt. Il empêche la création de domaines en double et valide l’ajout ou la suppression de domaines. Un seul rôle de Domain Naming Master existe par forêt.
`Relative ID (RID) Master`	Attribue des blocs de RID aux autres contrôleurs de domaine dans le même domaine. Chaque objet AD a un SID unique, composé du SID du domaine + un RID. Le RID Master garantit qu’aucun doublon ne soit attribué. Ce rôle existe une fois par domaine.
`PDC Emulator`	Ce contrôleur de domaine agit comme le DC principal pour : – l’authentification (en priorité) – les changements de mot de passe – la gestion des GPO – la synchronisation de l’heure dans le domaine Il est aussi essentiel pour la compatibilité avec d’anciens environnements (Windows NT). Il y a un PDC Emulator par domaine.
`Infrastructure Master`	Traduit les GUID, SID et DN entre objets provenant de domaines différents dans la même forêt. Ce rôle est critique dans les environnements multi-domaines, car il permet de garder les ACL à jour en résolvant correctement les objets étrangers. Un seul Infrastructure Master existe par domaine (sauf si tous les DCs sont aussi Global Catalogs).

Global Catalog

Le Global Catalog (GC) est un service spécial d’Active Directory, hébergé sur un ou plusieurs DC, qui contient une réplication partielle de tous les objets de la forêt.

Il stocke uniquement un sous-ensemble des attributs les plus utilisés pour les recherches (comme le sAMAccountName, mail, etc.).

Il permet :

d’effectuer des recherches rapides sur l’ensemble de la forêt
de localiser des objets sans interroger chaque domaine
d’authentifier un utilisateur lors d’une connexion en environnement multi-domaines

Le GC est essentiel dans les grandes forêts avec plusieurs domaines, car il facilite la visibilité globale sans tout dupliquer.

Read-Only Domain Controller (RODC)

Contrôleur de domaine en lecture seule, utilisé principalement dans des sites distants ou peu sécurisés.

Contrairement aux DC classiques, un RODC contient une copie de l’annuaire, mais ne permet pas les modifications locales : toutes les écritures doivent passer par un DC principal.

Caractéristiques principales :

lecture seule de la base AD
pas de réplication sortante (il reçoit les mises à jour, mais n’en envoie pas)
possibilité de ne pas stocker certains mots de passe localement (mot de passe caching sélectif)
réduction des risques en cas de compromission physique

Peut être idéal pour les bureaux distants avec un niveau de sécurité ou de connectivité limité.

Replication

La réplication est le processus par lequel les contrôleurs de domaine synchronisent entre eux les modifications apportées à la base Active Directory.

Elle permet de maintenir une cohérence entre tous les DC d’un domaine ou d’une forêt, même s’ils sont répartis sur différents sites.

Lorsqu’un nouveau DC est ajouté, des objets de connexion sont automatiquement créés pour établir les liens de réplication. Ces connexions sont gérées par le service KCC (Knowledge Consistency Checker), présent sur tous les DCs, qui calcule dynamiquement la topologie de réplication la plus efficace.

Il existe deux types de réplication :

intra-site : rapide, fréquente, sans compression (même site physique)
inter-site : plus lente, compressée, planifiée (entre sites distants)

Cette distinction n’est plus si importante aujourd’hui avec les très gros débit auxquels on a accès.

Chaque modification est enregistrée avec un identifiant de version (USN), et les DC utilisent un système de métadonnées pour résoudre les conflits éventuels. Pensez GitHub– (moins moins).

Service Principal Name (SPN)

Un SPN est un identifiant unique associé à une instance de service dans Active Directory. Il permet à Kerberos d’associer un service réseau à un compte d’utilisateur ou de machine, sans que le client ait besoin de connaître ce compte précisément.

Lorsqu’un client souhaite accéder à un service (par exemple HTTP, MSSQL, LDAP), il utilise le SPN pour demander un ticket Kerberos.

Le SPN permet donc à Kerberos de retrouver à quel compte appartient le service demandé, afin de générer le bon Ticket Granting Service (TGS, allez lire l’article Kerberos).

Kerberos expliqué avec 3 niveaux de détails

Exemples de SPN :

HTTP/serveur01.tarek.guru
MSSQLSvc/sql01.tarek.guru:1433

Un SPN mal configuré peut entraîner des erreurs d’authentification (comme des « double hop » ou des échecs de délégation Kerberos).

Group Policy Object (GPO)

Un GPO est un ensemble virtuel de paramètres de stratégie, utilisés pour gérer la configuration des utilisateurs et des ordinateurs dans un environnement Active Directory.

Chaque GPO possède un identifiant unique (GUID) et peut contenir des paramètres liés au système de fichiers local ou à Active Directory.

Les GPO peuvent être appliqués à :

l’ensemble du domaine
des unités d’organisation (OU) spécifiques
des groupes de sécurité via le filtrage de sécurité
des objets utilisateur ou ordinateur individuellement

Ils permettent de définir des règles comme :

les restrictions d’accès au panneau de configuration
la configuration réseau
l’exécution automatique de scripts
le déploiement d’applications

Les GPO sont traités selon un ordre précis (local, site, domaine, puis OU), et peuvent être forcés ou bloqués selon les besoins.

Access Control List (ACL)

Une ACL est une liste ordonnée d’entrées de contrôle d’accès (ACE) associées à un objet (fichier, dossier, objet AD, etc.).

Elle définit qui peut accéder à l’objet et de quelle manière. Chaque objet sécurisé possède au moins une ACL.

Il existe deux types principaux d’ACL :

DACL (Discretionary ACL) : contrôle les autorisations (autoriser ou refuser l’accès)
SACL (System ACL) : contrôle l’audit des accès (suivi des accès réussis ou échoués)

Access Control Entries (ACEs)

Une ACE est une ligne dans une ACL. Elle associe un trustee (utilisateur, groupe, ou session) à une ou plusieurs actions possibles :

autorisées
refusées
auditées

Chaque ACE précise :

le SID du trustee ciblé
le type d’accès (lecture, écriture, exécution, etc.)
le type d’action (allow, deny, audit)

L’ordre des ACE dans une ACL est important, car les refus (deny) sont généralement traités avant les autorisations (allow).

Discretionary Access Control List (DACL)

Une DACL définit quels principals de sécurité (utilisateurs, groupes, comptes de service) sont autorisés ou refusés à accéder à un objet.

Elle contient une liste d’ACE (Access Control Entries), chacune décrivant un droit autorisé ou refusé pour un principal donné.

Quand un processus tente d’accéder à un objet, le système parcourt la DACL dans l’ordre :

si une ACE correspondante autorise l’accès, l’accès est accordé
si une ACE refuse l’accès demandé, l’accès est immédiatement bloqué
si aucune ACE ne correspond, l’accès est refusé par défaut

Si un objet n’a pas de DACL, tout le monde a un accès complet.
Si la DACL est présente mais vide, aucun accès n’est autorisé, même pour les administrateurs.

System Access Control List (SACL)

Une SACL permet d’enregistrer les tentatives d’accès à un objet sécurisé dans les journaux de sécurité du système.

Les ACE de type SACL précisent quels types d’accès (lecture, écriture, suppression, etc.) doivent être audités et enregistrés, que la tentative réussisse ou échoue.

Cela permet aux administrateurs de suivre les accès sensibles pour des raisons de conformité, de sécurité ou d’analyse post-incident.

Fully Qualified Domain Name (FQDN)

Un FQDN est le nom complet d’un ordinateur ou d’un hôte dans une infrastructure DNS. Il identifie de façon unique une machine dans la hiérarchie du domaine, en partant du nom d’hôte jusqu’au domaine racine.

Structure :
[nom de l’hôte].[nom de domaine].[suffixe DNS]

Exemple :
Pour une machine nommée dc01 dans le domaine tarek.guru, le FQDN est
dc01.tarek.guru

Le FQDN est utilisé pour :

localiser un hôte sans connaître son adresse IP
permettre aux clients et services de résoudre les noms via DNS
identifier un objet dans un environnement Active Directory de manière unique

Il fonctionne comme un chemin absolu dans l’arborescence DNS, similaire à une URL complète sur Internet.

Tombstone

Un tombstone est un objet spécial utilisé par Active Directory pour marquer un objet comme supprimé sans le supprimer immédiatement de la base.

Lorsqu’un objet est supprimé dans un domaine qui n’a pas l’AD Recycle Bin activé, il devient un tombstone et est déplacé dans le conteneur Deleted Objects.

Les caractéristiques d’un tombstone :

l’attribut isDeleted est défini sur TRUE
la plupart des attributs sont supprimés (seuls quelques-uns sont conservés, comme le GUID et le SID)
il est conservé pendant une durée appelée tombstone lifetime

Par défaut :

60 jours sur les anciens DC (Windows Server 2003/2008)
180 jours sur les versions récentes, selon les recommandations Microsoft

Pendant cette période, l’objet supprimé est encore répliqué entre les contrôleurs de domaine, ce qui garantit que la suppression est bien prise en compte partout.

Une fois le délai dépassé, l’objet est définitivement purgé et ne peut plus être restauré (sauf à partir d’une sauvegarde).

Si l’AD Recycle Bin est activé, les objets sont conservés différemment, avec leurs attributs intacts, dans un état récupérable.

AD Recycle Bin

L’AD Recycle Bin est une fonctionnalité introduite avec Windows Server 2008 R2, permettant de restaurer des objets supprimés dans Active Directory sans avoir à redémarrer un contrôleur de domaine, arrêter les services AD DS, ni utiliser de sauvegarde.

Lorsqu’il est activé, les objets supprimés sont conservés dans un état récupérable pendant une période définie. Par défaut, cette période est de 60 jours si aucune durée personnalisée n’est spécifiée.

Contrairement au fonctionnement classique avec les tombstones, la corbeille AD conserve la majorité des attributs de l’objet supprimé (nom, appartenance aux groupes, SID, etc.), ce qui permet une restauration complète et fiable.

Avantages principaux :

restauration rapide via PowerShell ou l’interface graphique (à partir de Windows Server 2012)
pas de redémarrage nécessaire
préservation des attributs essentiels
évite de devoir restaurer tout un contrôleur depuis une sauvegarde

Une fois la période de rétention expirée, l’objet est définitivement supprimé, comme un tombstone classique.

SYSVOL

Le dossier SYSVOL est un répertoire partagé sur les contrôleurs de domaine qui contient des fichiers publics nécessaires au bon fonctionnement d’un environnement Active Directory.

Il contient notamment :

les scripts de logon/logoff et startup/shutdown
les paramètres des stratégies de groupe (GPO)
des fichiers de configuration partagés par tous les DCs du domaine

Les contenus de SYSVOL sont automatiquement répliqués entre tous les contrôleurs de domaine du même domaine.

Deux technologies peuvent être utilisées pour cette réplication :

FRS (File Replication Service) pour les anciens environnements
DFS-R (Distributed File System Replication) recommandé depuis Windows Server 2008 et requis à partir de 2016

Le bon fonctionnement de SYSVOL est essentiel pour que les GPO soient appliquées correctement sur les postes clients et pour que les scripts soient disponibles lors de la connexion des utilisateurs.

AdminSDHolder

AdminSDHolder est un objet spécial dans Active Directory utilisé pour protéger les comptes à privilèges élevés, comme les membres de Domain Admins, Enterprise Admins, ou Administrators.

Il contient un Security Descriptor (ACL) de référence, qui est appliqué automatiquement à tous les membres des groupes protégés.

Ce processus est géré par un mécanisme appelé SDProp (Security Descriptor Propagator), qui s’exécute toutes les heures par défaut sur le contrôleur de domaine tenant le rôle FSMO de PDC Emulator.

Quand SDProp s’exécute, il :

identifie les membres des groupes protégés
remplace leurs ACL par celles définies sur l’objet AdminSDHolder
empêche toute modification non autorisée des droits sur ces comptes

Cela empêche, par exemple, un attaquant de persister en ajoutant une ACE malveillante sur un compte admin : cette ACE sera écrasée à la prochaine exécution de SDProp.

AdminSDHolder est donc une couche de sécurité essentielle pour garantir que les comptes critiques restent correctement verrouillés.

dsHeuristics

L’attribut dsHeuristics est une chaîne de caractères définie sur l’objet Directory Service dans la configuration de la forêt Active Directory.
Il permet de contrôler plusieurs comportements globaux dans l’annuaire, en modifiant certaines options avancées au niveau de la forêt.

Parmi les paramètres qu’il peut influencer, on retrouve la possibilité d’exclure certains groupes intégrés de la liste des groupes protégés par AdminSDHolder.
Lorsque cette exclusion est activée via dsHeuristics, les membres du ou des groupes spécifiés ne seront plus soumis à la propagation automatique des ACL par le processus SDProp.
Cela signifie que les modifications de permissions sur ces objets ne seront pas réinitialisées à chaque exécution du SDProp.

L’attribut dsHeuristics est donc un levier puissant, mais sensible, utilisé uniquement dans des cas spécifiques, généralement en environnement maîtrisé.

adminCount

L’attribut adminCount est utilisé par Active Directory pour indiquer si un objet utilisateur est considéré comme protégé par le mécanisme AdminSDHolder.

Si adminCount vaut 1, cela signifie que l’utilisateur est (ou a été) membre d’un groupe protégé (comme Domain Admins, Enterprise Admins, etc.), et qu’il est donc sous la protection du processus SDProp.
Si la valeur est 0 ou non définie, l’utilisateur n’est pas protégé.

Les utilisateurs avec adminCount = 1 recevront automatiquement les ACL définies sur AdminSDHolder, et toute tentative de modifier leurs permissions sera écrasée à la prochaine exécution de SDProp.

Dans un contexte d’attaque interne, les comptes avec adminCount = 1 sont souvent ciblés, car ils ont un historique ou un statut de privilège élevé, et peuvent mener à une élévation de privilèges ou à une compromission du domaine.

Active Directory Users and Computers (ADUC)

ADUC est une console graphique (GUI) fournie par Microsoft pour gérer les objets Active Directory tels que les utilisateurs, groupes, ordinateurs, unités d’organisation (OU) et contacts.

Elle permet d’effectuer diverses actions administratives :

création, modification et suppression d’objets
gestion de l’appartenance aux groupes
déplacement d’objets entre OUs
définition de propriétés comme les mots de passe, les comptes expirés, les descriptions, etc.
application de stratégies de délégation

ADUC est largement utilisée dans les environnements Windows, mais toutes les opérations qu’elle permet peuvent également être réalisées via PowerShell, souvent de façon plus automatisable et scriptable.

Elle fait partie des RSAT (Remote Server Administration Tools) et doit être installée manuellement sur les postes clients si elle n’est pas déjà disponible.

ADSI Edit

ADSI Edit est un outil graphique avancé qui permet d’accéder et de modifier directement les objets et attributs dans Active Directory, bien au-delà des possibilités offertes par ADUC.

Il permet :

d’afficher et modifier tous les attributs d’un objet AD (même ceux non exposés dans ADUC)
d’ajouter, supprimer ou déplacer des objets manuellement
d’accéder à différentes partitions de l’annuaire (domain, configuration, schema, etc.)

ADSI Edit agit comme un éditeur de base de données AD en accès quasi brut. À ce titre, c’est un outil puissant mais risqué : une mauvaise manipulation peut provoquer des problèmes graves, voire une corruption partielle de l’annuaire.

Il est principalement utilisé pour :

la résolution de problèmes complexes
la gestion de cas spécifiques (modification manuelle d’attributs, nettoyage de métadonnées)
l’analyse de la structure profonde de l’AD

Son usage est réservé aux administrateurs expérimentés, et il est fortement recommandé de toujours opérer avec prudence ou sur un environnement de test.

sIDHistory

L’attribut sIDHistory contient une liste de SIDs précédemment attribués à un objet Active Directory, généralement un utilisateur ou un groupe.
Il est principalement utilisé lors de migrations inter-domaines, pour permettre à un utilisateur de conserver ses accès aux ressources, même si son SID principal a changé.

Concrètement, lorsqu’un utilisateur est migré d’un ancien domaine vers un nouveau, son ancien SID est ajouté à sIDHistory. Cela permet aux ACL configurées dans l’ancien domaine de continuer à le reconnaître.

Cependant, sIDHistory peut être abusé si mal sécurisé :

un attaquant pourrait injecter un SID d’un groupe à privilèges (ex. : Domain Admins) dans cet attribut
si SID Filtering n’est pas activé sur les relations d’approbation entre domaines, ce SID malveillant pourrait être accepté, menant à une élévation de privilèges

C’est une fonctionnalité utile en migration, mais qui nécessite un contrôle strict en environnement de production sécurisé.

NTDS.DIT

Le fichier NTDS.DIT est la base de données centrale d’Active Directory. Il est stocké localement sur chaque contrôleur de domaine, généralement dans le dossier C:\Windows\NTDS\.
Ce fichier contient l’ensemble des données critiques de l’annuaire :

objets utilisateurs, ordinateurs, groupes
appartenances aux groupes
attributs divers
et surtout, les hashs de mots de passe de tous les comptes du domaine

Ce fichier est une cible prioritaire pour les attaquants une fois un DC compromis. En extrayant NTDS.DIT, il est possible de récupérer les hashs et :

effectuer des attaques de type pass-the-hash
craquer les mots de passe hors ligne avec des outils comme Hashcat
accéder à des ressources protégées ou pivoter vers d’autres comptes

Dans certains cas rares, si la stratégie « Store passwords using reversible encryption« est activée, les mots de passe peuvent être enregistrés en clair dans la base, à condition qu’ils aient été créés ou modifiés après l’activation de cette option.

Cela peut se produire dans des environnements nécessitant des protocoles ou applications qui ne prennent pas en charge Kerberos.

MSBROWSE

MSBROWSE est un protocole hérité utilisé dans les premières versions de Windows pour fournir un service de navigation réseau au sein des réseaux locaux (LAN).

Il permettait de maintenir une liste visible de ressources partagées (imprimantes, dossiers, machines), facilitant la navigation depuis l’explorateur Windows.

Le système fonctionnait grâce à un Master Browser, une machine élue dynamiquement pour compiler et diffuser les listes des ressources disponibles.

On pouvait identifier le Master Browser via la commande nbtstat -A [adresse IP]. Si la sortie affichait MSBROWSE, cela indiquait que la machine était le Master Browser.

L’outil nltest permettait également d’interroger ce rôle pour découvrir les contrôleurs de domaine visibles sur le réseau.

Aujourd’hui, MSBROWSE est obsolète. Les réseaux Windows modernes utilisent les protocoles SMB (Server Message Block) et CIFS (Common Internet File System) pour la découverte et le partage de ressources.

Dans les environnements actuels, la découverte passe davantage par DNS, LDAP ou mDNS/LLMNR dans certains cas, plutôt que par des mécanismes de type browser list.

Dernier mot

Si vous êtes arrivé jusqu’ici, bravo. Peu de gens peuvent dire qu’ils ont lu un glossaire AD sans sombrer dans un coma léger, surtout après la section « Tombstone ».

Nous avions commencé cette exploration par une balade en forêt, entre objets, branches et feuilles. Nous la terminons, peut-être un peu plus fatigués, après ce long trail mais avec un regard neuf sur cet écosystème qu’est Active Directory. Derrière chaque terme, un usage. Derrière chaque usage, une intention — bonne ou moins bonne.

Il ne s’agissait pas ici de dresser un inventaire exhaustif ni d’imposer une vérité, mais d’ouvrir une porte. Celle d’une lecture plus fine, plus consciente, d’un composant trop souvent cantonné au technique et trop peu regardé.

Car même quand on fait de la gouvernance — surtout quand on en fait, oserait-on dire — une compréhension technique reste indispensable. Car c’est à cet endroit précis, entre le concept et l’implémentation, entre l’idée et la configuration, que se jouent les équilibres les plus sensibles.

Et maintenant ? N’hésitez pas à souscrire à la newsletter, promis je ne spamme pas <3

Tech Guru Tarek