À propos de ce guide

Ce guide décrit l'installation, la configuration et l'utilisation d'AdGUARD, l'outil de bureau d'audit de sécurité pour Active Directory. Il s'adresse aux consultants en sécurité, administrateurs d'annuaire et auditeurs qui évaluent la posture d'un ou plusieurs domaines Active Directory.

Aucune connaissance préalable de l'outil n'est requise. Les notions Active Directory (domaine, contrôleur de domaine, LDAP, délégations, Tier 0) sont supposées familières. Les captures d'écran sont décrites en clair lorsque cela aide à situer une fonction.

1. Introduction

1.1 Ce qu'est AdGUARD

AdGUARD est une application de bureau Windows qui audite la configuration de sécurité d'un domaine Active Directory. Elle interroge l'annuaire en lecture seule via LDAP, confronte la configuration réelle à un catalogue de 176 points de contrôle issus de cadres publics reconnus, puis produit un score de conformité, un détail contrôle par contrôle et des rapports exportables.

L'idée est simple. Un audit manuel d'Active Directory suppose de parcourir des dizaines d'écrans et de scripts, en notant les écarts dans un tableur. AdGUARD couvre le même périmètre en une poignée de secondes, de façon répétable, et conserve l'historique pour mesurer les progrès. Un simple compte utilisateur du domaine suffit pour l'essentiel des contrôles, ce qui rend l'outil utilisable dès la première réunion.

1.2 Principes de conception

1.3 Ce qu'AdGUARD ne fait pas

• Il ne remédie pas. Aucune correction automatique, aucune modification de l'annuaire. Les commandes PowerShell fournies sont informatives, à exécuter en connaissance de cause par un administrateur.
• Il ne surveille pas en continu. Un audit est une exécution ponctuelle et manuelle — une photographie de la configuration, pas un SIEM ni un outil de détection.
• Il n'audite pas Entra ID. Ce périmètre est couvert par EntraGUARD, bâti sur le même socle.
• Il n'analyse pas le contenu. L'application lit des paramètres de configuration et des métadonnées d'objets d'annuaire, jamais le contenu des fichiers ou des partages.
• Il ne remplace pas un audit humain. Il industrialise la partie mécanique et répétable, pour vous laisser le temps de l'analyse, du contexte et des recommandations.

1.4 Architecture fonctionnelle

L'application repose sur quelques composants : le connecteur établit l'accès en lecture à l'annuaire via LDAP ; le catalogue de contrôles décrit ce qu'il faut vérifier (176 points, rattachés à une catégorie, un palier de maturité et des correspondances de cadres) ; les lignes de base définissent le périmètre retenu ; le moteur d'audit exécute les contrôles et calcule un score ; les rapports présentent le résultat sous plusieurs angles. Une brique spécifique extrait les chemins d'attaque et les relations d'approbation (chapitre 14).

1.5 Terminologie

2. Installation et premier lancement

2.1 Prérequis

2.2 Installation

L'application est livrée sous forme d'un programme d'installation Windows standard (AdGUARD-Setup-x.y.z.exe, construit avec Inno Setup) :

• Lancez l'installateur avec un compte administrateur local.
• Il installe dans C:\Program Files\AdGUARD pour tous les utilisateurs du poste.
• Un raccourci du menu Démarrer est créé ; un raccourci sur le bureau est proposé en option.
• Au premier lancement, l'application crée sa zone de données partagée (§ 2.3).

Les mises à jour ultérieures s'installent par-dessus : l'identifiant d'application est stable, donc la version installée est détectée et remplacée. Les données — fiches, historique, connecteurs, licence — ne sont jamais touchées par une réinstallation, car elles vivent en dehors du dossier du programme.

2.3 Où vivent les données

Toutes les données résident sous une racine unique, partagée par tous les comptes Windows du poste. C'est un choix délibéré : sur un poste d'audit partagé, deux consultants doivent retrouver les mêmes fiches et le même historique.

C:\ProgramData\AdGUARD\
 ├── license.key            licence installée (partagée par tout le poste)
 ├── control-packs\         packs de contrôles importés (JSON)
 └── clients\
      ├── <domaine-1>\
      │    ├── settings.json  connecteur, export, logo, performance
      │    └── audit.db       base SQLite : historique et résultats détaillés
      └── <domaine-2>\
           └── ...

HKCU\Software\AdGUARD\ActiveClient   domaine sélectionné (par session Windows)

Le domaine actif est stocké par utilisateur Windows dans le registre : deux sessions ouvertes sur le même poste peuvent travailler sur deux domaines différents à la fois, tout en partageant le même ensemble de fiches.

2.4 Premier lancement

La prise en main se fait en cinq étapes :

• Activer la licence — Paramètres › Licence, collez la clé qui vous a été remise (§ 3.3).
• Créer le premier domaine — Domaines AD › Ajouter un domaine, en renseignant au moins le nom (§ 5.2).
• Relier l'annuaire — Paramètres › Connecteurs, configurez l'accès Active Directory (§ 6).
• Choisir le périmètre — Lignes de base › Modèles pour partir d'un cadre, ou Contrôles de sécurité pour choisir manuellement (§ 7 et § 10).
• Lancer le premier audit — Audit de sécurité › Exécution, puis exportez le rapport (§ 11 et § 15).

2.5 L'interface

La fenêtre se compose d'une barre latérale de navigation à gauche (domaines AD, contrôles de sécurité, lignes de base, audit, tableau de bord, chemins d'attaque, rapports, paramètres) et d'une zone de travail à droite. Le domaine actif est rappelé en permanence : toutes les actions s'appliquent à ce domaine. Un basculement de thème (clair / sombre) et de langue (français / anglais) est accessible à tout moment.

3. Licence et activation

3.1 Fonctionnement

La licence est vérifiée entièrement hors ligne, au moyen d'une signature asymétrique ECDSA sur courbe P-256 (empreinte SHA-256). L'éditeur signe le contenu de la licence avec une clé privée qui ne quitte jamais sa machine ; l'application embarque la clé publique correspondante, qui permet uniquement de vérifier une signature, jamais d'en produire une. Décompiler l'application ne permet donc pas de forger une licence, et il n'existe aucun serveur d'activation à joindre.

Le fichier de licence est un bloc de texte encadré par une armure lisible, à la manière d'une clé PEM :

-----BEGIN GUARD LICENCE-----
...contenu signé, encodé en base64url...
-----END GUARD LICENCE-----

Le contenu signé porte les informations suivantes :

3.2 D'où vient la licence : l'application GuardLicence

Les licences ne sont plus produites par un générateur intégré à l'application, comme c'était le cas dans les versions antérieures. Elles sont émises par une application dédiée, GuardLicence, détenue par l'éditeur et, le cas échéant, par ses partenaires habilités.

GuardLicence détient l'autorité de signature et fonctionne selon une chaîne à trois niveaux :

• une racine (la clé privée de l'éditeur) signe des certificats ;
• chaque certificat autorise l'émission de licences bornées : produits autorisés (EntraGUARD, AdGUARD), plafond de domaines, date d'échéance ;
• à partir d'un certificat, on émet des licences individuelles pour chaque client.

Ce modèle permet à l'éditeur de déléguer l'émission à un partenaire sans lui confier la racine : le partenaire ne peut émettre que dans les limites inscrites dans son certificat. L'application AdGUARD, elle, ne connaît que la clé publique racine et se contente de vérifier la licence reçue.

3.3 Activer une licence

Ouvrez Paramètres › Licence. Deux possibilités selon la façon dont la licence vous a été remise :

• Coller la clé : collez le texte complet de la licence, armure comprise, dans le champ prévu, puis validez.
• Charger un fichier : sélectionnez le fichier license.key fourni ; son contenu est lu et installé.

À l'activation, l'application vérifie successivement la signature, le produit (c'est bien une licence AdGUARD), l'échéance et le plafond de domaines. Elle affiche ensuite l'état de la licence, le nom du licencié, la date d'échéance et le nombre de domaines autorisés.

3.4 Les quatre états

L'état est déterminé au chargement de la licence puis réévalué en fonction de la date : une licence valide bascule automatiquement à Expirée le jour de son échéance.

3.5 Le quota de domaines

La licence fixe un nombre maximal de fiches domaine. Lorsque ce plafond est atteint, l'ajout d'un nouveau domaine est refusé, avec un message indiquant la limite en vigueur et le nombre de fiches déjà créées. Pour auditer davantage de domaines, il faut activer une licence au plafond plus élevé. Supprimer une fiche existante libère une place dans le quota.

3.6 Renouvellement et déploiement

Un renouvellement consiste simplement à activer une nouvelle licence à échéance plus lointaine : elle remplace la précédente, sans autre manipulation. Pour déployer la même licence sur plusieurs postes, distribuez le même fichier license.key et activez-le sur chacun ; la licence n'est pas liée à une machine particulière. Sur un poste partagé, la licence installée vaut pour tous les comptes Windows.

4. Nom de l'application et rapports

4.1 Le nom vient de la licence

Le menu Paramètres › Image de marque des versions précédentes, qui permettait de définir un nom, un slogan et un logo d'application ainsi qu'une identité d'émetteur, a été retiré. Le nom affiché par l'application — sur l'écran de démarrage, dans la barre de titre et en haut de la barre latérale — est désormais celui du licencié, tel qu'inscrit dans la licence.

Ce nom n'est plus modifiable manuellement : il s'impose dès qu'une licence est activée. Tant qu'aucune licence n'est chargée, l'application s'appelle « AdGUARD ».

4.2 Identité dans les rapports

Les rapports exportés (HTML, PDF) portent en en-tête et en pied de page le nom du licencié — c'est-à-dire le nom de l'application — accompagné de la date de génération. La personnalisation détaillée de l'émetteur qui existait auparavant (société, site web, adresse de contact, logo d'en-tête réglables dans Paramètres › Image de marque) n'est plus proposée : l'identité de l'émetteur dans les rapports se limite au nom porté par la licence.

4.3 Le logo du domaine audité

Le logo du domaine audité reste, lui, entièrement pris en charge — c'est une notion distincte de l'identité de l'émetteur. Depuis la fiche d'un domaine (§ 5.2), vous pouvez associer un logo : il apparaît sur la page de garde du rapport exécutif de ce domaine. C'est le logo du client audité, sur son propre rapport.

Visez une image nette, d'environ 180 px de haut, sur fond transparent ou blanc, aux formats PNG ou JPG. Ce logo est propre à chaque fiche : deux domaines peuvent avoir chacun le leur.

4.4 Thème et langue

L'application propose un thème clair et un thème sombre, ainsi qu'un basculement entre le français et l'anglais. Ces réglages sont disponibles dans les paramètres et s'appliquent immédiatement à toute l'interface, sans redémarrage. Ils sont indépendants de la licence et propres à chaque poste.

5. Gérer les domaines audités

5.1 Le portefeuille

La page Domaines AD liste l'ensemble des domaines que vous auditez. Chaque entrée est une fiche autonome : son connecteur, son historique d'audits et ses rapports lui sont propres. Une barre de recherche permet de retrouver rapidement un domaine lorsque la liste s'allonge.

5.2 La fiche domaine

La fiche d'un domaine rassemble son identité, son connecteur (chapitre 6), son logo de page de garde (§ 4.3) et son historique. Le nom du domaine est obligatoire : c'est lui qui identifie le domaine audité dans les rapports exportés.

5.3 Le domaine actif et la séparation des données

À tout moment, un seul domaine est actif : c'est celui sur lequel portent les audits, les résultats et les rapports affichés. Changer de domaine actif bascule tout le contexte de travail. Les données d'un domaine ne se mélangent jamais avec celles d'un autre : chaque fiche possède sa propre base SQLite.

6. Le connecteur Active Directory

6.1 Fonctionnement

Le connecteur est le point d'entrée technique de l'audit. Il ouvre un accès en lecture seule à l'annuaire via LDAP. Tant qu'il n'est pas configuré et testé, les contrôles restent verrouillés et n'entrent pas dans le score. Chaque fiche domaine a son propre connecteur.

6.2 Les champs

6.3 Les droits requis

Un simple utilisateur du domaine suffit pour la grande majorité des contrôles : la lecture des objets, de leurs attributs et de leurs descripteurs de sécurité est ouverte par défaut dans Active Directory. C'est ce qui rend AdGUARD utilisable dès la première réunion, sans processus administratif.

Quelques contrôles ciblent des objets à lecture restreinte, notamment le conteneur des services de certificats et certaines partitions de configuration. Sans droits sur ces objets, ces contrôles remontent non évalué, avec la raison — jamais « conforme ».

6.4 Tester et retirer

Le bouton Tester la connexion vérifie l'accès réel : un bind LDAP, puis une lecture effective d'un objet de l'annuaire. Un test en échec laisse le connecteur désactivé et verrouillé. L'application n'active jamais un connecteur dont l'accès n'a pas été prouvé — un audit reposant sur une source inaccessible produirait un score faussement rassurant.

Retirer la configuration efface les réglages locaux du connecteur. Rien ne change dans l'annuaire : AdGUARD n'y a jamais écrit.

6.5 Sécurité des identifiants stockés

Le mot de passe du compte de lecture est chiffré avec DPAPI à l'échelle de la machine. Un fichier de configuration copié sur une autre machine est illisible. En revanche, tous les comptes Windows de la machine peuvent le déchiffrer : c'est délibéré, puisqu'ils partagent le même poste d'audit.

Préférez l'authentification intégrée lorsque c'est possible : aucun mot de passe n'est stocké, et la traçabilité côté annuaire porte le nom de l'auditeur.

7. Contrôles et catégories

7.1 Le catalogue

L'application est livrée avec 176 contrôles couvrant les grands domaines de sécurité d'un annuaire Active Directory : fondations du Tier 0 (chemins d'attaque, délégations d'ACL, services de certificats AD CS · ESC, comptes et groupes privilégiés), Kerberos et protocoles hérités, secrets et chiffrement, comptes de service, relations d'approbation, LAPS, politiques et configuration (mots de passe, verrouillage, configuration du domaine, DNS d'annuaire, durcissement des contrôleurs, stratégies de groupe), hygiène de l'annuaire et détection, gouvernance. Le catalogue est compilé dans l'application : aucun fichier JSON n'est distribué à côté de l'exécutable, et il est disponible dès le premier lancement.

7.2 Anatomie d'un contrôle

Chaque contrôle porte les éléments suivants, tous présents dans l'interface et dans les exports :

7.3 Niveaux et sélection

Les contrôles sont hiérarchisés par palier de maturité ANSSI (chapitre 9), ce qui structure la lecture des résultats : un écart à un palier bas pèse davantage qu'un durcissement avancé. Avant un audit, vous choisissez les contrôles à exécuter ; la sélection peut être ponctuelle ou enregistrée sous forme de ligne de base (chapitre 10) pour être rejouée à l'identique.

7.4 Ajouter vos propres contrôles

Au-delà du catalogue fourni, l'application permet d'importer des packs de contrôles supplémentaires (au format JSON) pour adapter l'audit à votre méthodologie ou aux exigences d'un cadre interne. Les packs importés apparaissent aux côtés des contrôles intégrés et participent aux lignes de base comme les autres.

8. Cadres de conformité

8.1 Le principe de correspondance

Les contrôles sont mis en correspondance avec des cadres reconnus (CIS, NIST, ISO 27001, ANSSI, MITRE ATT&CK…). Un même contrôle peut ainsi contribuer à plusieurs cadres, ce qui permet de lire un audit sous l'angle réglementaire ou normatif qui intéresse le client, sans réexécuter quoi que ce soit.

8.2 Couverture

La couverture indique, pour chaque cadre, la part des exigences éclairées par les contrôles exécutés. Le rapprochement avec MITRE ATT&CK est particulièrement parlant pour Active Directory : il relie chaque écart aux techniques d'attaque qu'il rend possibles.

9. Le modèle de maturité ANSSI

9.1 Le principe

Chaque contrôle est rattaché à un palier de 1 à 5. Le niveau atteint est le palier N le plus élevé tel qu'il ne reste aucun contrôle non conforme aux niveaux 1 à N. On ne peut donc pas revendiquer un palier supérieur tant qu'un écart persiste à un palier inférieur — c'est ce qui distingue cette lecture d'un simple pourcentage.

9.2 Les cinq paliers

La concentration du catalogue sur le palier 1 — 89 contrôles sur 176 — n'est pas un déséquilibre : elle reflète la réalité de la sécurité des annuaires, où l'essentiel du risque se situe dans le Tier 0 et les délégations.

10. Lignes de base

10.1 Ce qu'est une ligne de base

Une ligne de base est le périmètre d'audit convenu : la liste des contrôles retenus, ceux écartés, et les éventuels ajustements de palier. C'est l'objet qui rend un audit répétable et défendable — sans elle, la question « pourquoi ce contrôle n'a-t-il pas été évalué ? » n'a pas de réponse documentée. Elle est définie par un nom, un périmètre (global ou propre à un client), une description en texte libre où sont consignées les raisons des exclusions, et la liste des contrôles inclus, exclus et re-nivelés.

10.2 Modèles et éditeur

Des modèles prêts à l'emploi sont fournis. Chacun sélectionne les contrôles correspondant à un critère (un cadre, un palier) et exclut le reste ; les décomptes affichés sont calculés à partir du catalogue réel, jamais figés. Chaque carte affiche deux chiffres : combien de contrôles le modèle retient, et combien d'entre eux sont réellement exécutables avec le connecteur actuellement configuré et les droits disponibles. L'éditeur permet ensuite d'ajuster la sélection, de nommer la ligne de base, de choisir son périmètre et de l'enregistrer.

11. Lancer un audit

11.1 Préparation

Avant de lancer un audit, assurez-vous que le domaine visé est actif, que son connecteur est configuré et testé, et que la ligne de base ou la sélection de contrôles correspond à ce que vous souhaitez évaluer.

11.2 Déroulement

L'audit exécute les contrôles retenus en lisant l'annuaire, attribue un verdict à chacun (conforme, non conforme, non évalué), puis calcule le score et le palier de maturité atteint. L'avancement est affiché en cours d'exécution. À la fin, le résultat est enregistré dans l'historique de la fiche et immédiatement consultable. Un audit complet dure typiquement une poignée de secondes.

12. Résultats, historique et comparaison

12.1 Lire les résultats

Le résultat d'un audit présente, contrôle par contrôle, l'état constaté et le palier, avec le score global et le niveau de maturité ANSSI atteint. On peut filtrer par catégorie, par palier ou par verdict pour se concentrer sur les écarts. Les contrôles non évalués sont clairement signalés, avec leur raison. Chaque contrôle non conforme expose sa remédiation et, le cas échéant, sa commande PowerShell informative.

12.2 Historique

Chaque audit est horodaté et conservé dans la base de la fiche. L'historique d'un domaine permet de suivre l'évolution de sa posture dans le temps et de rouvrir n'importe quel audit passé.

12.3 Comparer deux audits

La comparaison met en regard deux audits d'un même domaine et fait ressortir ce qui a changé : améliorations, régressions, contrôles nouvellement conformes ou nouvellement en écart, progression du palier de maturité. C'est l'outil idéal pour mesurer l'effet d'une remédiation entre deux passages.

13. Le tableau de bord

Le tableau de bord offre une vue de synthèse du domaine actif : score global, palier de maturité ANSSI atteint, répartition des résultats par catégorie et par palier, points saillants et tendance au fil des audits. Il met en avant les chemins d'attaque les plus critiques et sert de point d'entrée pour décider où porter l'attention.

14. Chemins d'attaque et approbations

14.1 Ce qu'est un chemin d'attaque

Un chemin d'attaque est un droit détenu par un principal non privilégié sur un objet critique, lui permettant d'en prendre le contrôle. Ce n'est pas une vulnérabilité logicielle : c'est une délégation légitime devenue dangereuse, souvent accordée des années plus tôt pour une raison qui n'existe plus. AdGUARD extrait ces chemins des constats des contrôles et les dessine sous forme de graphe : à gauche le principal qui détient le droit, à droite l'objet ciblé, et entre les deux une arête colorée selon la gravité du droit.

14.2 Lire un chemin

Le chiffre à surveiller n'est pas le nombre total de chemins, mais le nombre de chemins partant d'un principal auquel tout utilisateur du domaine appartient. Ceux-là sont à la portée de n'importe quel compte, y compris un compte compromis par hameçonnage.

14.3 Les relations d'approbation

Les relations d'approbation (trusts) entre domaines élargissent la surface d'attaque : un compromis dans un domaine approuvé peut se propager. AdGUARD recense les relations d'approbation du domaine audité et signale celles qui présentent une configuration à risque, afin de les intégrer à l'analyse.

15. Rapports et exports

15.1 Les formats

Les résultats peuvent être exportés dans plusieurs formats adaptés au partage : rapport HTML et PDF (mise en page soignée, imprimable) et données tabulaires pour retraitement. Tous les rapports portent en en-tête et en pied de page le nom du licencié et la date de génération (§ 4.2). Les identifiants de contrôle, paliers et correspondances de cadres apparaissent à l'identique dans tous les formats.

15.2 Le rapport exécutif

Le rapport exécutif est une synthèse destinée aux décideurs. Sa page de garde peut porter le logo du domaine audité (§ 4.3). Il présente le score global, le palier de maturité atteint, les chemins d'attaque majeurs et les priorités, sans exiger de connaissance technique fine. D'autres angles éditoriaux (technique, plan d'action) permettent d'adresser des publics différents à partir du même audit.

16. Performance

La durée d'un audit dépend du nombre de contrôles retenus et de la taille de l'annuaire (nombre d'objets à lire). Restreindre la sélection à une ligne de base ciblée accélère l'exécution. Le traitement étant local, les performances dépendent aussi du poste utilisé et de la latence réseau vers le contrôleur de domaine. Les paramètres de performance sont ajustables dans les réglages de la fiche.

17. Annexes

17.1 Emplacements des fichiers

Toutes les données résident sous C:\ProgramData\AdGUARD\ : la licence (license.key), les packs de contrôles importés, et un dossier par fiche contenant ses réglages (settings.json) et sa base d'historique (audit.db). Le domaine actif est mémorisé par utilisateur Windows dans le registre (HKCU\Software\AdGUARD\ActiveClient). Les rapports exportés sont écrits à l'emplacement que vous choisissez au moment de l'export.

17.2 Raccourcis clavier

Les actions courantes (lancer un audit, exporter, naviguer entre les sections) sont accessibles au clavier. La liste des raccourcis est consultable depuis l'aide de l'application.

17.3 Dépannage