Active Directory : ce que vous devez savoir sur la sécurité des mots de passe

I. Présentation

Pour de nombreuses organisations, l'Active Directory (AD) est au cœur de la gestion des identités dans leur environnement Windows. Il stocke les informations d'authentification des utilisateurs, y compris leurs mots de passe, qui constituent une donnée précieuse. Afin de garantir leur sécurité, l'Active Directory utilise des mécanismes spécifiques et recourt à des fonctions de hachage pour éviter de stocker les mots de passe en clair.

Cet article a pour objectif d’expliquer comment les mots de passe sont stockés dans la base de données AD et quels en sont les risques en matière de sécurité. Nous présenterons également une solution gratuite permettant d’identifier les faiblesses des mots de passe.

II. Comment Active Directory stocke les mots de passe ?

La base de données de l'Active Directory est contenue dans le fichier NTDS.dit, stocké par défaut dans le répertoire C:\Windows\ntds\NTDS.dit. Sa structure repose sur un ensemble de tables destinées à stocker les informations de l'annuaire Active Directory. Parmi ces tables, certaines enregistrent des informations sur les objets (utilisateurs, ordinateurs, groupes, etc.), d'autres sur les liens entre ces objets, ainsi que sur les descripteurs de sécurité des objets, appelés ACE (Access Control Entries).

Ce fameux fichier NTDS.dit stocke également une donnée sensible : les empreintes cryptographiques des mots de passe, c'est-à-dire le hash des mots de passe. Cela signifie que les mots de passe des utilisateurs ne sont pas stockés en clair dans Active Directory.

Un algorithme de hachage va calculer le hash d'un mot de passe avant de l'enregistrer dans la base de données. Il s'agit d'un mécanisme de type "one-way function" (OWF) décrit de cette façon dans la documentation de Microsoft : "Une "One-way function" est un terme qui désigne une transformation mathématique à sens unique des données. Les données transformées ne peuvent être converties par cryptage que dans un sens et ne peuvent être inversées."

Sur le papier, le hash d'un mot de passe peut sembler incassable, mais ce n'est pas si simple. Si un attaquant parvient à voler un hash, il peut tenter de le "casser" pour obtenir le mot de passe en clair. Il existe plusieurs méthodes connues, de la simple attaque brute force à la méthode basée sur des Rainbow Tables. C'est pour cette raison que le choix de l'algorithme est important. Il y en a des plus robustes que d'autres. L'évolution des machines, et de la puissance de calcul associée, met en péril la robustesse de certains algorithmes (MD4, MD5, LM, par exemple).

L'Active Directory exploite les deux fonctions de hachage suivantes :

• LM Hash (LAN Manager Hash)
• NT Hash (lié à NTLM)

Note : les mots de passe Active Directory ne sont pas salés (salted). Pour rappel, le salage consiste à ajouter une partie aléatoire à un mot de passe avant de l'envoyer à la fonction de hachage. Cela permet d'augmenter les résistances à certaines attaques, notamment par brute force.

A. La méthode LM Hash

Le format LM est le plus ancien et il est considéré comme obsolète depuis près de 20 ans. LM Hash présente la particularité de prendre en compte seulement 14 caractères. Voici les principales étapes du mécanisme utilisé :

• Si le mot de passe fait moins de 14 caractères, une action de bourrage complète la chaine pour qu'elle soit égale à 14 caractères (NULL).
• Convertit tout le mot de passe en majuscules (insensible à la casse)
• Divise le mot de passe en deux blocs de 7 caractères.
• Utilise DES (Data Encryption Standard) pour chiffrer chaque bloc, qui seront ensuite assemblés.

Remarque : si le mot de passe fait plus de 15 caractères, la valeur générée sera incomplète et ne pourra pas être utilisée pour authentifier l'utilisateur.

Vous devez savoir que la génération du LM Hash est désactivée par défaut depuis Windows Vista et Windows Server 2008. Microsoft propose également un paramètre de stratégie de groupe (GPO) pour forcer sa désactivation. Cela peut s'avérer utile sur les environnements où l'historique fait que le paramètre est encore actif (pour des raisons de rétrocompatibilité).

À partir de l'éditeur de stratégie de groupe, vous pouvez configurer ce paramètre. Il se situe à l'emplacement suivant : Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Option de sécurité.

Ce paramètre s'intitule de cette façon : "Sécurité réseau : ne pas stocker de valeurs de hachage de niveau LAN Manager sur la prochaine modification de mot de passe". Vous devez définir ce paramètre et l'activer. Tout en sachant qu'il s'agit déjà du comportement par défaut avec Windows Server 2008 et les versions plus récentes.

Attention, ce paramètre de stratégie de groupe n'est pas disponible sur Windows Server 2025. Ce n'est pas une surprise puisque Microsoft a amélioré la sécurité sur ce point dans Windows Server 2025. D'ailleurs, cette phrase que nous pouvons lire sur le site de Microsoft sert de transition pour la suite de cet article : "NTLMv1 a été supprimé dans Windows Server 2025, toutes les autres versions de NTLM, y compris LANMAN et NTLMv2, ne sont plus sous développement de fonctionnalités actives et sont déconseillées."

B. La méthode NT Hash

Dans les années 90, Microsoft a introduit à Windows un nouveau format pour protéger les mots de passe : NT (New Technology). Cela remonte à l'époque de Windows NT, donc le choix de ce nom n'est probablement pas un hasard. Aujourd'hui encore, l'Active Directory s'appuie sur cette méthode pour stocker les mots de passe dans l'Active Directory. D'ailleurs, le hash NT est lié à un protocole d'authentification que vous connaissez probablement : le NTLM, dont la version 1 est fortement déconseillée.

Le NT Hash est obtenu à l'aide de l'algorithme MD4, utilisé pour hacher les mots de passe, à la place du DES utilisé par LM. Il y a également d'autres différences notables :

• Longueur du mot de passe : il peut gérer des mots de passe jusqu'à 256 caractères, mais il y a une limite à 127 caractères dans la console d'administration AD.
• Sensibilité à la casse : contrairement au LM Hash, le NT Hash est sensible à la casse, ce qui augmente la sécurité du hachage.
• Hachage unique : le mot de passe est haché en une seule fois, sans être divisé en deux blocs.

Le condensat NT (ou hash NT) d'un mot de passe est stocké dans la base d'annuaire Active Directory et représente une donnée sensible.

III. Le chiffrement réversible des mots de passe

A. L'option "Enregistrer le mot de passe en utilisant un chiffrement réversible"

Désormais, nous allons évoquer une option présente au niveau de chaque objet AD appartenant à la classe user et qui représente un risque en matière de sécurité.

Les comptes à risques sont ceux dont l'option "Enregistrer le mot de passe en utilisant un chiffrement réversible" est activée dans les options de compte. Activer cette option offre l'opportunité de récupérer en clair le mot de passe, ce qui ne respecte pas le mécanisme "one-way function" évoqué précédemment. Mais attention, si vous cochez cette option sur un compte, cela n'est pas à effet immédiat : c'est le prochain mot de passe de l'utilisateur en question qui sera stocké de façon réversible.

Remarque : cette notion est également accessible lors de la création d'une stratégie de mots de passe affinée et elle porte l'intitulé "Stocker le mot de passe en utilisant un chiffrement réversible". L'option s'applique alors à tous les comptes sur lesquels s'appliquent la stratégie de mots de passe.

Quand cette option est activée, elle va avoir un impact sur l'attribut ms-DS-User-Encrypted-Text-Password-Allowed. Inutile de le rechercher par l'intermédiaire de l'éditeur d'attributs ou en parcourant le schéma Active Directory, vous ne le trouverez pas ! En effet, la documentation Microsoft mentionne que l'état de cet attribut est visible au travers de l'attribut UserAccountControl.

Donc, avec l'Active Directory, cet attribut n'est pas visible dans la liste des attributs du schéma. A contrario, il est visible dans ADAM (Active Directory Application Mode), une version d’Active Directory conçue exclusivement pour les applications (pour jouer le rôle d'annuaire LDAP uniquement, sans la couche authentification). Considérez ADAM comme un ancêtre du rôle ADLDS.

• Active Directory - Découverte de l'attribut UserAccountControl

En exécutant un script PowerShell (que vous pouvez retrouver dans l'article cité ci-dessus), vous pouvez "convertir" la valeur UserAccountControl et afficher les flags actifs. Dans le cas de l'utilisateur pour lequel l'option a été activée précédemment, nous pouvons voir la présence du flag nommé ENCRYPTED_TEXT_PWD_ALLOWED. Il prouve que l'option a été cochée dans les paramètres du compte et qu'il y a un impact direct sur la valeur de l'attribut UserAccountControl.

À l'aide de PowerShell, vous pouvez énumérer tous les comptes Active Directory où l'option "Enregistrer le mot de passe en utilisant un chiffrement réversible" est cochée :

Get-ADUser -filter {AllowReversiblePasswordEncryption -eq $True} -Properties "AllowReversiblePasswordEncryption"

B. Lire un mot de passe stocké en clair dans AD

Lorsque cette option est cochée, il est possible de récupérer les mots de passe AD en clair, sans devoir passer par l'étape de "cassage de mots de passe" que nous évoquerons dans la suite de cet article. Une technique repose notamment sur l'exploitation de l'attaque DCSync à l'aide d'un outil comme Mimikatz ou Impacket.

Vous pouvez lire nos articles sur l'attaque DCSync pour approfondir le sujet :

• Active Directory : qu’est-ce que l’attaque DCSync ?
• Active Directory : comment détecter l’exploitation de DCSync au sein d’un domaine ?

Si nous prenons l'exemple de Mimikatz, la commande ci-dessous permet d'obtenir le mot de passe en clair pour un utilisateur spécifique.

mimikatz # lsadump::dcsync /domain:it-connect.local /user:florian.burnel

Le résultat en image :

Il en va de même avec l'utilisation de secretsdump d'Impacket :

impacket-secretsdump -just-dc IT-CONNECT.LOCAL/<VULNERABLE_DCSYNC_ACCOUNT>@192.168.14.201

Le résultat en image :

Enfin, le cmdlet Get-ADReplAccount du module DSInternals permet aussi d'atteindre notre objectif. Il doit bénéficier d'autorisations similaires à celles de l'attaque DCSync.

Get-ADReplAccount -SamAccountName florian.burnel -Domain it-connect -Server SRV-ADDS-01

Le résultat en image :

Comme vous pouvez le constater, à cause de l'option "Enregistrer le mot de passe en utilisant un chiffrement réversible", il est possible de récupérer directement le mot de passe. Il faut tout de même tenir compte des prérequis pour en arriver-là, notamment l'attaque DCSync qui nécessite plusieurs prérequis.

IV. Extraire les hash des mots de passe de l'Active Directory

Attention - Ce qui suit est présenté à titre informatif et éducatif, et doit être appliqué uniquement dans un contexte où vous disposez des autorisations nécessaires.

Il existe plusieurs outils pour extraire les hash des mots de passe stockés dans la base Active Directory. La première étape consiste à effectuer une copie de la base ntds.dit pour extraire les informations. Le problème, c'est qu'il n'est pas possible de faire un simple copier-coller de ce fichier sur un contrôleur de domaine en ligne, car il est protégé.

Plusieurs méthodes plus ou moins bruyantes, à appliquer en fonction du contexte, sont accessibles. Nous pouvons citer notamment les outils natifs ntdsutil, vssadmin et DiskShadow (en ajoutant aussi l'outil reg). Il y a aussi un outil offensif nommé Invoke-NinjaCopy, qui est un script PowerShell.

Par exemple, la commande suivante (qui est en réalité un enchainement de commandes) permet de réaliser l'export des informations grâce à une sauvegarde des données. L'option ifm fait référence à la création d'un support pour l'installation d'un contrôleur de domaine à partir d'un média USB (IFM).

ntdsutil "activate instance ntds" "ifm" "create full C:\Temp\NTDS" quit quit

Au-delà de créer une copie de la base ntds.dit, il est nécessaire également d'exporter la ruche du Registre correspondante au chemin "C:\Windows\system32\config\SYSTEM", car elle contient la clé permettant de déchiffrer la base d'annuaire.

Ensuite, les hachages des mots de passe peuvent être lus à l'aide de plusieurs outils. Nous pouvons prendre comme exemple le module PowerShell DSInternals. Voici un exemple d'utilisation :

# Charger la clé
$BootKey = Get-BootKey -SystemHivePath "C:\TEMP\NTDS\registry\SYSTEM"

# Lister les informations sur tous les comptes Active Directory
Get-ADDBAccount -All -DBPath "C:\TEMP\NTDS\Active Directory\ntds.dit" -BootKey $BootKey

Il est alors possible de cibler un compte spécifique, par exemple, le compte Administrateur du domaine.

Get-ADDBAccount -DistinguishedName "CN=Administrateur,CN=Users,DC=it-connect,DC=local" -DBPath "c:\temp\NTDS\Active Directory\ntds.dit" -BootKey $BootKey

Si nous regardons de plus près les informations retournées par la commande, nous pouvons voir la valeur NTHash : 2b391dfc6690cc38547d74b8bd8a5b49 ! Le LMHash quant à lui est vide, ce qui est cohérent sur un environnement sous Windows Server 2025.

Il est également possible d'obtenir une liste compacte avec uniquement les noms des comptes et les HashNT. Ainsi, nous pouvons constater quelque chose d'intéressant (et d'inquiétant en production) : les comptes Administrateur et florian.burnel ont le même mot de passe ! Le hash est identique entre ces deux comptes, et en l'absence de salage, nous avons obligatoirement la même valeur.

Cette valeur peut être exploitée avec d'autres outils dans le but de tenter de casser le mot de passe. Ce qui renforce l'idée qu'il est indispensable d'utiliser des mots de passe robustes, pour qu'ils soient très difficiles à casser.

Un outil comme Hashcat peut être utilisé pour réaliser des attaques par brute force ou par dictionnaire sur le NTHash obtenu précédemment. L'exemple ci-dessous repose sur l'utilisation d'un dictionnaire de mots de passe représenté par le fichier passwords.txt, tandis que la valeur à casser est présente dans le fichier nommé hashes.txt. À chaque fois qu'il y a un résultat positif, il sera ajouté au fichier de sortie cracked.txt.

hashcat -m 1000 -a 0 -o cracked.txt hashes.txt passwords.txt

L'option -m sert à préciser le type de hash : la valeur 1000 correspond à NTLM. L'option -a 0 sert à préciser qu'il s'agit d'une attaque basée sur un fichier de dictionnaire. Quelques secondes plus tard, Hashcat a terminé son analyse et nous pouvons constater qu'il est parvenu à casser le mot de passe ! L'administrateur du domaine utilise donc le mot de passe P@ssword! !

2b391dfc6690cc38547d74b8bd8a5b49:P@ssword!

Ici, il s'agit d'un cas très simple avec un mot de passe inacceptable en production. Néanmoins, cela montre les risques associés à l'utilisation de mots de passe faibles, et potentiellement, l'utilisation de mots de passe compromis.

V. Auditer les mots de passe Active Directory

Lorsqu'il est question d'auditer les mots de passe de l'Active Directory, il y a un outil gratuit qui me vient tout de suite en tête : Specops Password Auditor. Ce n'est pas le seul outil de la sorte, mais il présente l'avantage d'être accessible en interface graphique, et surtout, de générer un rapport en français prêt à l'emploi.

Ce logiciel va notamment analyser les points suivants :

• Conformité des politiques de mots de passe (ANSSI, CNIL, NIST, BSI, etc.)
• Comptes avec des mots de passe vides
• Comptes avec des mots de passe ayant fait l'objet d'une fuite de données (mots de passe compromis)
• Comptes avec des mots de passe identiques
• Comptes administrateur du domaine
• Comptes administrateur non protégés contre la délégation
• Comptes administrateur et utilisateurs inactifs
• Comptes où le mot de passe n'est pas obligatoire
• Comptes où le mot de passe n'expire jamais
• Comptes où le mot de passe est configuré pour expirer
• Comptes où le mot de passe est expiré
• L'âge du mot de passe sur chaque compte utilisateur / administrateur
• Liste des politiques de mots de passe avec les caractéristiques clés (dont l'entropie)
• Utilisation / affectation des politiques de mots de passe

Ce logiciel gratuit s'appuie une base de mots de passe compromis locale qui contient plus de 1 milliard de mots de passe. Pour aller plus loin dans l'analyse, il est nécessaire de passer sur Specops Password Policy, une solution payante, avec plus de fonctionnalités et qui bénéficie d'une base avec plus de 4 milliards de mots de passe.

Vous pouvez retrouver notre article de présentation complet sur cette page (et notre vidéo YouTube).

• Identifiez les mots de passe compromis dans l’Active Directory

VI. Conclusion

Comme nous l'avons vu, l'Active Directory s'appuie sur plusieurs algorithmes pour le hachage des mots de passe. Le hash NT est le seul que nous devons rencontrer sur les environnements récents, et pour autant, il n'est pas sans défaut.

Cet article met en lumière deux grandes recommandations :

• Ne pas utiliser l'option "Enregistrer le mot de passe en utilisant un chiffrement réversible" sur les comptes des utilisateurs (à auditer régulièrement !)
• Utiliser des mots de passe robustes pour les comptes des utilisateurs, afin de se protéger contre les attaques ciblant les NT Hash (et les LM Hash).

Cet article inclut une communication commerciale pour Specops Software.