Architecture d'Active Directory : confiance et délégation

Dans presque toutes les entreprises de taille moyenne ou grande, une même brique gouverne qui peut se connecter à quoi : l'annuaire Active Directory. C'est la clé de voûte du réseau, et c'est pour cette raison qu'elle est au cœur de la plupart des tests d'intrusion internes. Avant de parler d'attaque, cette première leçon pose le décor : comment l'annuaire est organisé, ce que signifient « confiance » et « délégation », et pourquoi ces notions créent des risques.

Dans le cours précédent, vous avez appris la méthode complète d'un test d'intrusion. Ici, nous changeons d'échelle : au lieu d'une machine isolée, nous regardons le réseau d'une organisation, avec ses centaines de comptes et de postes. Le fil rouge de ce cours est la construction de votre portfolio d'apprenti white hat ; la première pièce sera un schéma commenté d'un petit annuaire de laboratoire.

Un annuaire, une autorité centrale

Imaginez la mairie d'une ville. Elle tient le registre des habitants, décide qui a le droit d'entrer dans quel bâtiment et délivre des justificatifs. Active Directory joue ce rôle dans un réseau Windows : il garde la liste des utilisateurs, des groupes, des ordinateurs et des services, et il vérifie l'identité de chacun lors d'une connexion.

Concrètement, le service d'annuaire s'exécute sur des serveurs appelés contrôleurs de domaine (DC, pour domain controller). Plusieurs DC se répliquent entre eux : si l'un tombe, les autres continuent de répondre. Quiconque contrôle un contrôleur de domaine contrôle, en pratique, toute l'organisation. C'est ce qui explique l'intérêt des attaquants.

Les briques d'organisation

L'annuaire est structuré à plusieurs niveaux. Retenez ce vocabulaire, il reviendra dans toutes les leçons du chapitre.

• Le domaine : une frontière d'administration et de sécurité, avec son nom (par exemple atelier.lab dans notre laboratoire fictif). Il regroupe des comptes et des machines.
• L'arbre : un ensemble de domaines qui partagent un espace de noms contigu (atelier.lab et paris.atelier.lab).
• La forêt : un ensemble d'arbres qui partagent le même annuaire de base. La forêt, et non le domaine, est la véritable frontière de sécurité : c'est un point important que beaucoup d'administrateurs découvrent tard.
• Les unités d'organisation (OU) : des dossiers dans lesquels on range comptes et machines pour leur appliquer des règles ou déléguer leur gestion.
• Les stratégies de groupe (GPO) : des ensembles de paramètres appliqués automatiquement aux machines et aux utilisateurs (politique de mot de passe, pare-feu, restrictions…).

Pensez aux poupées russes : un domaine est rangé dans un arbre, lui-même dans une forêt, et à l'intérieur du domaine, les OU permettent d'organiser et de déléguer.

Comment l'annuaire vérifie qui vous êtes

Deux protocoles d'authentification coexistent généralement. Kerberos est le protocole moderne : il fonctionne avec des « tickets » délivrés par le contrôleur de domaine, que nous détaillerons dans la troisième leçon. NTLM est un protocole plus ancien, conservé pour la compatibilité, et plus fragile. Lorsqu'un service ne peut pas utiliser Kerberos, le système retombe parfois sur NTLM, ce qui laisse une porte ouverte que l'on cherche à fermer progressivement lors du durcissement.

Un autre mécanisme à retenir : l'annuaire est conçu pour être consultable par tous les utilisateurs authentifiés. Un employé ordinaire peut, par défaut, lister une grande partie des comptes et des groupes, car beaucoup d'applications en ont besoin. Ce choix de conception rend la collecte d'informations possible depuis un simple compte standard, nous y reviendrons dans la leçon suivante.

La confiance entre domaines et entre forêts

Quand deux organisations fusionnent, ou quand une entreprise possède plusieurs sites, il faut permettre aux utilisateurs d'un domaine d'accéder aux ressources d'un autre. C'est le rôle des approbations (trusts). Une approbation est une relation de confiance : le domaine A accepte de croire ce que dit le domaine B sur l'identité de ses utilisateurs.

Trois caractéristiques décrivent une approbation :

• Sa direction : à sens unique ou bidirectionnelle. Dans une approbation à sens unique, A fait confiance à B, mais pas l'inverse.
• Sa transitivité : si A fait confiance à B et B à C, une approbation transitive permet à A de faire (indirectement) confiance à C.
• Son périmètre : entre domaines d'une même forêt, entre forêts, ou vers des domaines externes.

L'analogie est celle des accords de reconnaissance de diplômes entre pays : plus le réseau d'accords est vaste et transitif, plus il est pratique, et plus un diplôme falsifié dans un pays peut avoir de conséquences dans un autre. Pour un auditeur, une approbation est donc un chemin potentiel d'un périmètre vers un autre. Une approbation oubliée après une fusion, avec un partenaire dont la sécurité est plus faible, est un grand classique des rapports d'audit.

La délégation : prêter son identité à un service

Voici le concept le plus subtil de la leçon. Imaginez que vous demandez à un site de réservation de consulter votre agenda en votre nom. Le site doit pouvoir agir comme vous auprès d'un autre service. Dans un domaine, on appelle cela la délégation : un service reçoit le droit de se présenter à d'autres services en utilisant l'identité d'un utilisateur.

Il existe plusieurs formes, par ordre décroissant de risque :

• La délégation non contrainte : le serveur reçoit une copie utilisable du ticket de l'utilisateur et peut l'utiliser vers n'importe quel autre service. C'est la forme la plus dangereuse, car quiconque compromet ce serveur peut potentiellement réutiliser les identités qui s'y connectent, y compris celles d'administrateurs.
• La délégation contrainte : le serveur ne peut agir que vers une liste précise de services. Le risque est mieux borné.
• La délégation basée sur les ressources : c'est la ressource cible qui décide quels services ont le droit d'agir en son nom. Le contrôle est plus fin, mais il dépend de qui a le droit de modifier cette configuration.

Retenez le principe plutôt que les détails : déléguer, c'est étendre la confiance. Chaque délégation doit être justifiée, limitée et documentée, car elle agrandit la surface que l'attaquant pourrait exploiter après avoir pris pied sur une machine.

Pourquoi un attaquant s'intéresse à cette architecture

Un attaquant qui obtient un premier accès (un poste d'employé, par exemple) ne cherche pas à rester sur ce poste. Il cherche à se déplacer latéralement et à monter en privilèges jusqu'aux comptes qui gouvernent l'annuaire. Les approbations, les délégations larges, les groupes imbriqués et les comptes de service trop puissants dessinent des chemins qu'il peut suivre. À l'inverse, un défenseur qui comprend l'architecture voit les mêmes chemins et peut les couper. C'est tout l'esprit du « hacking éthique » : penser comme l'attaquant pour protéger.

À vous de jouer

Objectif : produire la première pièce de votre portfolio, un schéma commenté d'un annuaire de laboratoire fictif.

1. Sur papier ou avec un outil de schéma, dessinez une forêt nommée atelier.lab contenant un domaine racine et un domaine enfant paris.atelier.lab.
2. Placez dans chaque domaine un contrôleur de domaine, trois OU (Utilisateurs, Serveurs, Postes) et deux groupes (Comptabilité, Administrateurs informatiques).
3. Ajoutez une approbation bidirectionnelle vers une seconde forêt fictive partenaire.lab, et un serveur applicatif appli-devis bénéficiant d'une délégation non contrainte.
4. Annotez en rouge les deux endroits qui vous semblent les plus risqués et expliquez pourquoi en une phrase chacun.

La leçon suivante part de ce schéma : nous verrons comment un auditeur autorisé fait l'inventaire d'un annuaire et pourquoi la représentation en « graphe » a transformé ce travail.