I. Présentation
La réglementation NIS2 incite les entreprises concernées à mieux se préparer aux cyberattaques, et par conséquent, à augmenter le niveau de sécurité de leur domaine Active Directory. En effet, avec NIS2, le périmètre de responsabilité s’élargit et les attentes en matière de cybersécurité sont plus strictes. Dans le contexte d’un Active Directory, les entreprises doivent mettre en œuvre des mécanismes solides de protection et de surveillance autour des comptes utilisateurs et administrateurs de l’annuaire.
Cet article propose un ensemble de recommandations, de pistes de réflexion et d’outils pour renforcer Active Directory et répondre aux exigences de NIS2 en matière de gestion des identités. L’Active Directory étant encore omniprésent dans les entreprises, sa mise en conformité avec NIS2 représente un challenge pour de nombreux DSI et RSSI.
Cet article inclut une communication commerciale pour Specops Software.
II. Comprendre les attentes de NIS2
Sans entrer dans les détails juridiques qui obligent certaines organisations à être en conformité sous peine de sanction, NIS2 impose une logique de cyber-résilience démontrable. Le mot-clé est preuve, et dans le contexte de la gestion des identités, cela implique de : prouver que les identités sont maîtrisées, prouver que les accès sont contrôlés, prouver que les actions sensibles sont surveillées.
Ainsi, nous pouvons déjà identifier plusieurs axes d’amélioration :
Adopter des contrôles d’identification et d’authentification robustes, avec l’intégration d’un MFA résistant aux attaques, par exemple.
Sécuriser les identités privilégiées, les comptes de service et tous les comptes sensibles d’une manière générale.
Appliquer une approche Zero Trust, en particulier pour la gestion des privilèges.
Gérer les risques liés aux mots de passe, notamment les mots de passe compromis, faibles ou réutilisés.
Produire des preuves assurant la traçabilité : journaux (logs), rapports, et même des indicateurs de conformité.
NIS2 n’impose pas un outil spécifique, mais il attend un résultat. Cet article est donc l’opportunité de comparer ces attentes aux fonctionnalités natives de l’Active Directory, et voir si elles y répondent ou non.
III. Durcir la politique de mots de passe AD
Une stratégie de mots de passe définit les règles imposées aux utilisateurs (et aux administrateurs) pour définir le mot de passe de leur compte. Cette stratégie détermine d’une certaine façon si les identifiants seront robustes et résistants aux attaques modernes. Aujourd’hui, on peut considérer qu’elle doit privilégier la longueur (et donc les passphrases) plutôt que la simple complexité historique.
A. Les recommandations
Pour mieux s’aligner avec NIS2 et les recommandations de l’ANSSI, nous devons identifier des solutions techniques permettant de s’orienter vers ces recommandations :
Prioriser la longueur à la complexité (les passphrases sont plus efficaces et elles font souvent plus de 16 caractères).
Arrêter de demander aux utilisateurs des expirations périodiques inutiles, sauf suspicion d’incident bien entendu.
Surveiller des listes de mots de passe compromis et leur utilisation au sein de l’AD local.
Rotation obligatoire des mots de passe associés aux comptes privilégiés, y compris pour les privilèges locaux (avec Windows LAPS couplé à AD, par exemple).
Surveiller les changements de mots de passe et le verrouillage des comptes (un pic de verrouillage de comptes doit être considéré comme suspect).
Personnellement, en l’absence de mécanisme de passwordless au sein d’AD, les passphrases me semblent beaucoup plus avantageuses que les mots de passe complexes. Une passphrase telle que “Montagne-Hiver-Serveur-Café” est plus résistante qu’un mot de passe complexe et plus simple à mémoriser (et même à saisir !).
B. Les outils natifs de l’Active Directory
Pour durcir la stratégie de mots de passe Active Directory, il y a deux approches possibles avec les outils natifs : une politique globale définie par l’intermédiaire d’une stratégie de groupe et des stratégies granulaires (Fine-Grained Password Policies correspondantes aux objets PSO) qu’il est possible d’appliquer directement à des groupes de sécurité (et qui peuvent être multiples).
Le problème, c’est que cette approche traditionnelle ne répond pas aux besoins actuels en matière de protection des identités :
Elle repose sur un paramètre de gestion de la complexité qui n’est pas assez flexible. AD ne peut pas empêcher un utilisateur d’utiliser un mot de passe extrêmement commun du moment qu’il respecte les critères de complexité, même s’il gère une notion d’historique pouvant apporter un peu de contrainte.
Elle n’inclut aucune détection des mots de passe compromis.
Malgré tout, il y a un point positif : on peut lui associer une stratégie de verrouillage de comptes AD pour verrouiller automatiquement les comptes s’il y a trop d’échecs de connexions dans un court intervalle de temps.
Exemple d’une politique de mot de passe affinée
C. Les solutions techniques
Les fonctionnalités natives intégrées à l’Active Directory pour gérer les mots de passe n’évoluent pas depuis plusieurs années, à l’exception des évolutions sur les comptes de service. Elles ne permettent pas de répondre à l’ensemble des recommandations actuelles. De ce fait, il faut s’orienter vers des solutions tierces, des solutions “faites maison” ou basées sur le Cloud de Microsoft pour obtenir une réponse technique concrète.
Voici deux exemples envisageables :
Microsoft Entra Password Protection, un agent à déployer sur les contrôleurs de domaine et qui s’appuie sur un service de vérification Entra ID. Il permet de détecter l’utilisation de mots de passe faibles ou compromis et d’interdire l’utilisation de certains mots de passe.
Specops Password Policy, une solution très complète capable de couvrir tous les aspects des recommandations actuelles : stratégies de passphrases alignées avec les bonnes pratiques de l’ANSSI et la détection de l’utilisation de mots de passe compromis de façon continue.
PowerShell, par l’intermédiaire de scripts, offre aussi la possibilité de surveiller l’utilisation des mots de passe compromis en s’appuyant sur un service comme Have I Been Pwned, par l’intermédiaire de son API. Un script pourrait comparer le hash des mots de passe avec la base de hash du service HIBP (une recherche à partir d’un hash partiel est possible, afin d’éviter d’exposer des informations sensibles).
Pour autant, ces solutions ne répondent pas au besoin de tracer les actions liées aux mots de passe et à l’activité des comptes. Ces événements, visibles via le journal d’audit (“Sécurité”) de l’Observateur d’événements, sont générés par Windows à partir du moment où la stratégie d’audit est correctement configurée. En complément, l’outil gratuit Sysmon est recommandé pour générer des logs plus précis et pour certains événements non tracés par défaut par Windows (ce qui facilite l’identification d’actions malveillantes).
La centralisation des logs dans un puits de logs ou dans un SIEM facilitera la corrélation des événements et la détection des comportements suspects. À ce sujet, on peut citer quelques solutions : Graylog, ELK et Microsoft Sentinel (SIEM Cloud). Ils permettront de surveiller des événements importants, comme par exemple :
ID de l’événementType d’événement4625Échec de connexion à une session.4720Un compte utilisateur a été créé.4723Un utilisateur a tenté de changer son propre mot de passe.4724Tentative de modification d’un mot de passe d’un autre utilisateur.4740Un compte utilisateur a été verrouillé.4771Un problème de pré-authentification Kerberos.4794Tentative de modification du mot de passe DSRM.
Aperçu de l’interface d’ELK
IV. L’Active Directory et le MFA
L’authentification MFA combine au moins deux facteurs indépendants pour vérifier l’identité d’un utilisateur et réduire le risque de compromission. Par exemple, un mot de passe et un code à usage unique (TOTP).
A. Les recommandations
Dans le contexte de NIS2, l’authentification multifacteurs (MFA) est obligatoire. Surtout, il est nécessaire d’aller au-delà du MFA basique afin d’opter pour des méthodes capables de résister au phishing ou aux attaques de type MFA fatigue.
Aujourd’hui, il est préférable de ne plus utiliser le MFA basé sur un simple Accepter/Refuser en push sur le smartphone (vulnérable à la technique évoquée précédemment), ni même le code par SMS. En effet, le MFA par SMS est considéré comme vulnérable car il repose sur un canal de communication facilement détournable. Un code envoyé par SMS peut être intercepté ou récupéré par un attaquant via plusieurs techniques (ingénierie sociale, malwares, SIM swapping, etc.).
B. Les outils natifs de l’Active Directory
Le problème avec le MFA, c’est que l’Active Directory est totalement dépourvu de cette fonctionnalité. Il n’intègre pas de mécanisme natif pour mettre en place le MFA, et c’est même une lacune qui s’étend jusqu’à Windows.
Pour durcir l’authentification sur les machines Windows au-delà du MFA, il est possible de s’appuyer sur des clés de sécurité FIDO2 (authentification par carte à puce / Smart Card) et l’authentification basée sur des certificats.
Pour ceux qui ont une infrastructure hybride liée à Entra ID, il y a aussi une opportunité d’authentification sans mot de passe, comme l’explique cette documentation de Microsoft.
C. Les solutions techniques
En réponse à ce besoin, il est tout de même envisageable d’ajouter du MFA à l’Active Directory par l’intermédiaire de solutions tierces qui impliquent d’installer un agent, y compris sur les postes de travail. Le MFA est alors ajouté en tant que surcouche. Il existe plusieurs solutions sur le marché, dont Specops Secure Access qui a fait l’objet d’une présentation technique sur IT-Connect et qui ajoute la prise en charge du MFA dans plusieurs scénarios :
Ouverture d’une session sur un ordinateur ou un serveur Windows
Connexion via le Bureau à distance (sur un serveur RDS, par exemple)
Connexion à distance VPN, à condition de s’appuyer sur NPS (authentification Radius)
Même si cette solution prend en charge le MFA par SMS, pour des raisons de compatibilité, elle supporte d’autres méthodes comme le code à usage unique (TOTP), la validation par empreinte biométrique ou par reconnaissance faciale et les clés de sécurité physique comme les YubiKey.
V. Gestion des comptes et des privilèges Active Directory
La gestion des comptes repose sur une hygiène rigoureuse visant à limiter la présence de comptes inutiles et inactifs, car ils représentent une surface d’attaque directe. La gestion des comptes et de leur cycle de vie est aussi une question d’hygiène en matière de maintenance d’un annuaire Active Directory. Ces mêmes comptes sont associés à des privilèges offrant plus ou moins de permissions à l’échelle du SI, et ces permissions doivent être suivies et révisées.
A. Les recommandations
Les administrateurs doivent prêter attention à plusieurs types de comptes à risque :
Les comptes dormants, c’est-à-dire tous les comptes inactifs mais activés dans AD, car ils agrandissent la surface d’attaque et sont parfois moins surveillés.
Les comptes de service, car ils sont souvent associés à des privilèges élevés (alors que ce n’est pas forcément nécessaire).
Les comptes d’administration disposant de privilèges élevés sur les postes de travail et/ou tout ou partie des serveurs.
Ce qui implique de gérer le cycle de vie des comptes utilisateurs (de la création à la désactivation voire la suppression) et surtout de prêter attention aux privilèges attribués à chaque compte utilisateur. Les principes de moindres privilèges et de cloisonnement doivent être appliqués, ce qui nous invite à nous intéresser à plusieurs concepts liés au durcissement de l’Active Directory :
Réduire le nombre de comptes “Admins du domaine” (pensez à garder un compte bris de glace).
Mettre en place des tiers d’administration (Tiering Model) : Tier 0, Tier 1, Tier 2.
Limiter l’attribution permanente des privilèges et prioriser l’affectation Just-in-time en particulier pour les groupes sensibles.
B. Les outils natifs de l’Active Directory
Nous venons d’évoquer plusieurs pistes pour améliorer la sécurité des comptes et la gestion des privilèges. En réponse, l’Active Directory intègre plusieurs fonctionnalités pour nous accompagner dans cette démarche :
Une date d’expiration automatique peut être configurée sur chaque compte (donc si vous connaissez la date de fin de contrat d’une personne, vous pouvez la spécifier dès le départ)
Les stratégies de groupe, les groupes de sécurité et les silos d’authentification permettent de mettre en œuvre l’administration en tiers, et donc d’assurer un bon cloisonnement au niveau des privilèges.
La fonctionnalité de PAM de l’Active Directory (niveau fonctionnel Windows Server 2016 minimum) intègre une fonctionnalité “Temporary Group Membership” permettant d’ajouter un utilisateur à un groupe de façon temporaire.
La gestion de comptes de service de façon propre avec les gMSA (ou les dMSA, nouveauté de Windows Server 2025 mais vulnérables déjà à plusieurs reprises). L’intérêt d’un gMSA, c’est notamment de bénéficier d’un mot de passe sécurisé, géré par AD et dont la rotation est automatique.
C. Les solutions techniques
En complément des outils natifs intégrés à l’Active Directory, et pour aller plus loin, notamment dans l’automatisation et la surveillance, il y a plusieurs outils auxquels vous pouvez vous intéresser.
Pour la gestion du cycle de vie des utilisateurs, vous pouvez compter sur PowerShell et la création d’un script personnalisé basé sur les résultats de la commande Search-ADAccount pour identifier et traiter les comptes AD inactifs (depuis 6 mois, par exemple). En complément, l’outil CleanupMonster permet de détecter les comptes ordinateurs inactifs et de les désactiver et/ou supprimer automatiquement, selon plusieurs règles définies par vos soins. Cet outil open source et gratuit est basé sur PowerShell.
Pour le suivi des privilèges, l’outil gratuit Specops Password Auditor peut vous aider à identifier les comptes privilégiés associés à un mot de passe faible ou compromis, voire même les comptes avec un mot de passe identique. Les faiblesses liées aux mots de passe peuvent rendre vulnérables certains comptes, et donc donner accès aux privilèges associés dans le cas d’une compromission de comptes. C’est donc un axe d’analyse complémentaire.
Enfin, pour la mise en place du Tiering Model au niveau de l’Active Directory, l’outil open source HardenAD, développé par une communauté d’experts Active Directory, permet de mettre en œuvre un modèle complet et éprouvé pour durcir l’Active Directory (y compris avec la gestion des protocoles obsolètes).
Bien d’autres solutions existent, ici, j’ai cité uniquement des outils déjà évoqués sur IT-Connect.
VI. Conclusion
Active Directory reste un système central et fréquemment ciblé. Son durcissement est non seulement une exigence NIS2, mais un impératif de sécurité fondamental pour toute organisation : l’AD est une cible privilégiée par les attaquants. Les outils et les recommandations précisés dans cet article devraient vous aider dans votre réflexion et dans cette démarche.
En complément, gardez à l’esprit que dans le cadre de NIS2, vous devez journaliser, auditer et documenter votre configuration et l’activité de votre système d’information. Comme j’évoquais précédemment, et c’est particulièrement vrai pour cet axe d’amélioration, la centralisation des logs (avec un SIEM) est essentielle.
Vous devez envisager de générer des rapports périodiques sur l’état de vos comptes (y compris avec les incidents) et d’intégrer des procédures claires pour plusieurs actions comme celles-ci : Comment un mot de passe est réinitialisé ? Comment l’identité du demandeur est vérifiée ? Etc… L’idée étant de structurer vos processus et de prouver que c’est effectif par la technique. Autrement dit, vous devez prouver que les identités sont maîtrisées, supervisées et durcies.
FAQ Mots de passe Active Directory et NIS2
Pourquoi est-il nécessaire de renforcer la sécurité des mots de passe Active Directory pour NIS2 ?
NIS2 impose des contrôles renforcés sur les accès et exige la mise en place de l’authentification multifacteurs pour renforcer la sécurité sur les services critiques. En environnement Active Directory, l’authentification préalable à un accès étant effectuée par un identifiant et un mot de passe, cela rentre dans le périmètre de NIS2.
NIS1 et NIS2 : quelles différences ?
NIS2 renforce et étend considérablement la portée de NIS1, entrée en vigueur en août 2016. NIS2 augmente le nombre de secteurs concernés (avec notamment les ESN), introduit des obligations de sécurité plus strictes et impose une responsabilité accrue aux dirigeants (des sanctions financières sont prévues). La directive NIS2 met également l’accent sur la gestion des identités, la résilience opérationnelle et la production de preuves techniques (logs, audits, supervision).
Pourquoi est-il inutile de forcer les utilisateurs à renouveler leur mot de passe AD ?
Forcer un renouvellement régulier des mots de passe AD est inutile car cela pousse les utilisateurs à choisir des mots de passe plus faibles, prévisibles ou simplement incrémentés, ce qui est contreproductif et va réduire la sécurité réelle du compte. Désormais : un mot de passe doit être long, robuste, inchangé, et ne doit être renouvelé que s’il est suspecté d’être compromis.
Pour cette raison, il est intéressant de surveiller les comptes AD pour voir si les mots de passe utilisateurs font l’objet d’une compromission (une fuite sur un autre service, si l’utilisateur réutilise son mot de passe sur plusieurs sites, par exemple).
Le MFA est-il natif à l’Active Directory ?
Non, l’Active Directory (on-premise, à ne pas confondre avec Entra ID) ne propose pas de mécanisme MFA natif pour l’authentification Kerberos (ni même pour NTLM). Pour activer le MFA dans un environnement AD, il faut passer par une solution tierce. Specops Secure Access est un exemple de solution propriétaire permettant d’ajouter le MFA sur Windows en environnement Active Directory.
Qu’est-ce qu’une attaque MFA fatigue ?
Il s’agit d’une technique d’ingénierie sociale où un attaquant, ayant déjà obtenu le mot de passe d’un utilisateur, enchaîne des demandes d’approbation MFA répétées qui arrivent sur le smartphone de l’utilisateur. L’objectif est d’épuiser ou de perturber la victime jusqu’à ce qu’elle accepte par erreur l’une des notifications, permettant ainsi à l’attaquant de se connecter.
En réalité, ce type d’attaque contourne les méthodes MFA basiques basées sur l’approbation simple (Accepter/Refuser) et exploite la pression psychologique plutôt qu’une faille technique dans le logiciel.
Pourquoi le MFA SMS n’est-il plus considéré comme sécurisé ?
Le MFA par SMS est vulnérable à plusieurs techniques d’attaque :
SIM swapping : vol du numéro de téléphone via l’opérateur
Interception réseau
Malwares capables de lire les SMS sur l’appareil mobile
Bien que ce soit une méthode d’authentification multifacteur valide, elle n’est pas recommandée.
Comment surveiller l’activité des comptes AD ?
Le journal d’audit “Sécurité” accessible via l’Observateur d’événements regroupe les logs relatifs aux actions suspectes effectuées sur les comptes Active Directory. On peut notamment citer quelques exemples :
4625 : échec de connexion à un compte utilisateur
4723 : un utilisateur a tenté de changer son mot de passe,
4724 : un utilisateur a tenté de changer le mot de passe d’un autre utilisateur,
4740 : un compte utilisateur a été verrouillé (cas d’un brute force)
Pourquoi centraliser les logs AD est indispensable pour NIS2 ?
La centralisation des logs a plusieurs avantages :
Garantit l’intégrité des journaux,
Recevoir des alertes en temps réel,
Faciliter la production de preuves (et surtout la conservation des preuves),
Faciliter les investigations, grâce à la corrélation des événements,
Détecter les activités suspectes.
On peut citer plusieurs solutions comme Graylog, ELK, Splunk, ou encore le très complet Wazuh.
Ingénieur système et réseau, cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.