Le gestionnaire d’annuaire

1. NTDS

La base de données principale d’Active Directory, NTDS.dit, est un fichier situé généralement dans le dossier C:\Windows\NTDS qui contient toutes les données relatives à l’annuaire, telles que les comptes utilisateurs, les groupes, les ordinateurs, les unités organisationnelles et bien d’autres objets. Ce fichier est situé sur chaque contrôleur de domaine et utilise un moteur de base de données appelé ESE (Extensible Storage Engine), ou Jet Blue, qui permet une gestion performante et sécurisée des données.

Le fichier NTDS.dit est organisé sous forme de plusieurs tables internes qui servent à stocker et organiser les objets de l’annuaire. L’une des tables principales est la datatable, qui contient les informations sur les objets de l’annuaire et leurs attributs, comme le nom d’utilisateur. D’autres tables, comme la link_table et la sd_table, gèrent respectivement les relations entre les objets (comme les appartenances aux groupes) et les descripteurs de sécurité qui définissent les permissions d’accès aux objets.

Les colonnes de la datatable ne portent pas de noms explicites, mais utilisent une convention de nommage interne reposant sur un préfixe suivi d’un identifiant. Par exemple, une colonne nommée ATTm590045 correspond à l’attribut sAMAccountName, c’est-à-dire le nom de connexion de l’utilisateur. Ce nom suit une logique propre au moteur ESE : le préfixe ATT indique qu’il s’agit d’un attribut, la lettre qui suit (comme m, j ou q) désigne le type de données stockées, et le nombre représente l’identifiant unique de l’attribut dans le schéma Active Directory.

Cette structure, bien que performante pour le moteur, est peu lisible et compréhensible directement par un humain. C’est pourquoi plusieurs outils ont été développés pour parser et interpréter les fichiers .dit :

Enfin, en 2021, Microsoft a publié le code source de son moteur ESE sur GitHub (https://github.com/microsoft/Extensible-Storage-Engine), offrant ainsi une visibilité précieuse sur le fonctionnement interne de cette base, longtemps restée opaque. Cela permet aujourd’hui aux chercheurs, pentesters et administrateurs d’auditer, comprendre ou exploiter cette base avec des outils mieux documentés.

2. Les partitions d’annuaire

Dans Active Directory, les données sont organisées en plusieurs partitions d’annuaire (ou naming contexts), qui sont des divisions logiques permettant de structurer l’annuaire selon différents critères. Ces partitions sont essentielles pour gérer la réplication des données entre les contrôleurs de domaine et pour organiser les objets de l’annuaire en fonction de leur domaine ou de leur rôle.

Voici les principales partitions utilisées dans Active Directory :

1. Les conteneurs

Un conteneur est un objet prédéfini par le système, conçu pour contenir d’autres objets Active Directory. Contrairement aux OU (Organizational Units), les conteneurs sont des structures de base, non conçues pour une organisation hiérarchiques, principalement utilisées pour regrouper certains objets de manière fonctionnelle. Ils sont créés automatiquement par le système et ne peuvent ni être modifiés ni supprimés. Par ailleurs, ils ne peuvent pas contenir d’OU et il n’est pas possible d’y appliquer directement des GPO (Group Policy Object).

Exemples de conteneurs par défaut :

2. Les unités d’organisation

Contrairement aux containers, les OU sont créées par les administrateurs et permettent de structurer l’annuaire de manière logique et hiérarchique.

Les OU servent à :

3. msDS-ShadowPrincipalContainer

Le conteneur msDS-ShadowPrincipalContainer...

1. Les utilisateurs

Dans Active Directory, les utilisateurs sont représentés par des objets de type user, qui constituent l’unité centrale pour la gestion des identités et des accès au sein d’un environnement Windows. Ces objets authentifiables disposent d’un ensemble d’attributs variés permettant à la fois de contrôler les accès (via userAccountControl, adminCount, pwdLastSet, accountExpires, memberOf, etc.) et de stocker des données personnelles ou organisationnelles. Ces données sont particulièrement utiles pour alimenter des annuaires d’entreprise, des intranets ou des applications RH.

Parmi les attributs les plus couramment utilisés à cette fin, on retrouve :

Active Directory prend également en charge d’autres types d’objets pour représenter des individus, comme contact et inetOrgPerson, qui répondent à des besoins spécifiques. Le tableau suivant en résume les principales différences :

Le Centre d’administration Active Directory offre une interface conviviale et intuitive, permettant de manipuler et de visualiser plus facilement les attributs des objets, en fournissant une vue détaillée et structurée qui facilite leur gestion et modification.

Création d’utilisateur ADAC

Depuis les propriétés de l’objet, l’Éditeur d’attributs, accessible via le menu Extensions, permet de consulter la valeur d’attributs plus techniques, tels que adminCount, qui indique si un compte utilisateur appartient à un groupe administratif ou bénéficie de privilèges élevés.

1. Le domaine

Un domaine est une partition dans une forêt Active Directory. Il regroupe un ensemble d’objets tels que des utilisateurs, ordinateurs, groupes ou ressources (imprimantes, dossiers partagés, etc.).

Dans un réseau en workgroup (groupe de travail), chaque ordinateur gère ses propres utilisateurs et ses propres règles. Ce modèle devient rapidement inefficace dans un environnement professionnel dans la mesure où il n’y a pas de gestion unifiée, les mots de passe doivent être synchronisés manuellement, et aucune politique de sécurité cohérente ne peut être appliquée à l’ensemble du parc.

Le domaine, à l’inverse :

1. Une interface d’interrogation standardisée

LDAP est utilisé par de nombreux composants d’un environnement Windows : par les interfaces d’administration comme la console Utilisateurs et ordinateurs Active Directory, les scripts PowerShell, les services d’applications, mais aussi des systèmes externes qui doivent interroger ou synchroniser l’annuaire.

Il repose sur un modèle client/serveur. Le client établit une connexion avec un contrôleur de domaine, généralement sur le port :

Une fois la connexion établie, le client peut :

1. Les mots de passe

Le mot de passe peut être stocké à différents endroits, en clair, chiffré ou haché, directement dans le programme d’authentification, dans un fichier ou dans une base de données. Un mot de passe est stocké en clair lorsqu’il est directement lisible. Il est chiffré lorsqu’il a subi certaines transformations pour être stocké sans être lisible. Les opérations inverses seront alors effectuées pour récupérer et vérifier le mot de passe. Enfin, un mot de passe est dit haché lorsque des opérations irréversibles ont été effectuées pour le stocker. À la vérification, ces mêmes opérations seront appliquées à la saisie de l’utilisateur. Le résultat (le condensat) sera alors comparé à ce qui est stocké. L’égalité garantit que le mot de passe saisi est le bon. Avec le hachage, la sécurité repose sur le fait que les transformations irréversibles ne donnent généralement pas deux résultats identiques pour deux mots de passe différents. Si c’est le cas, on parle de collision.

Le hachage est la méthode la plus couramment utilisée, car elle ne permet pas de retrouver le mot de passe à partir de l’information sauvegardée. Mais un autre problème se pose car l’utilisation d’un même mot de passe par deux utilisateurs fournira le même hachage. Un procédé appelé salage ajoute une séquence de bits non liée directement au mot de passe (par exemple un mot généré aléatoirement) avant le hachage. Cela permet d’éviter d’avoir des hachages identiques pour des mots de passe identiques.

Ainsi, la manière dont les mots de passe sont stockés et protégés conditionne directement le niveau de sécurité d’un système. Même avec des mécanismes robustes comme le salage et le hachage, les informations d’authentification doivent être gérées avec soin en mémoire et lors des échanges. C’est précisément le rôle du LSASS (Local Security Authority Subsystem Service) sous Windows, qui centralise et protège les secrets liés à l’authentification et à la gestion des identités.

2. LSASS

Windows ne se limite pas à un unique protocole d’authentification. Il propose une architecture modulaire s’appuyant sur un sous-système dédié, appelé LSASS, capable de déléguer les opérations d’authentification à une série de composants spécialisés appelés SSP (Security Support Providers).

L’ensemble de cette architecture est accessible via l’interface SSPI (Security Support Provider Interface), utilisée par toutes les applications et services Windows souhaitant authentifier un utilisateur. Cette interface permet aux applications de s’authentifier sans avoir à implémenter directement les protocoles d’authentification. Elle est l’équivalent Microsoft...

1. Introduction

Dans tout environnement réseau structuré, le DNS joue un rôle central. Il constitue le système d’adressage logique de l’Internet et des réseaux d’entreprise, traduisant des noms de domaine lisibles par l’homme (comme www.microsoft.com) en adresses IP exploitables par les machines. Sans DNS, la navigation web, la messagerie électronique et l’authentification dans un environnement Active Directory deviennent extrêmement limitées, manuelles, voire impossibles.

Le DNS repose sur une architecture hiérarchique, distribuée et résiliente. À son sommet se trouvent les serveurs racine, identifiés par une simple notation point (.), qui orientent les requêtes vers les serveurs de domaine de premier niveau (TLD), tels que .com, .org ou .fr. Ces derniers délèguent la gestion des domaines spécifiques à des serveurs autoritaires, désignés par les détenteurs de chaque nom de domaine.

Dans l’écosystème DNS public, deux acteurs clés participent à cette organisation : le registry et le registrar. Le registry est l’autorité technique qui gère un TLD donné, par exemple l’AFNIC pour .fr ou Verisign pour .com. Il maintient la base de données centrale des noms enregistrés et publie les serveurs faisant autorité. En parallèle, le registrar est un prestataire accrédité, comme OVH ou Gandi, qui vend et enregistre des noms de domaine pour le compte des utilisateurs. Lorsqu’un domaine est acheté, le registrar communique avec le registry pour l’ajouter à la base globale du DNS. Certains registrars proposent également un service d’hébergement DNS, prenant en charge la gestion technique de la zone du client.

Un processus de résolution DNS peut être récursif ou itératif. Dans le cas d’une résolution récursive, c’est le résolveur DNS (généralement fourni par l’opérateur ou l’entreprise) qui prend en charge l’intégralité de la chaîne de requêtes jusqu’à obtenir la réponse finale. À l’inverse, une requête itérative reçoit des redirections successives vers des serveurs de plus en plus spécifiques, jusqu’à atteindre le serveur autoritaire. Cette distinction est essentielle pour comprendre les flux réseau et diagnostiquer d’éventuels dysfonctionnements.

Le système DNS s’appuie sur des enregistrements structurés appelés Resource Records. Les plus courants sont les enregistrements A (adresse IPv4) et AAAA (adresse IPv6), mais d’autres types remplissent des fonctions cruciales : CNAME pour les alias, MX pour la messagerie, NS pour la délégation de zones, SRV pour la publication de services, PTR pour la résolution inverse, et TXT pour les vérifications...