LaBouaBouate

LM Hash dans Active Directory

#activedirectory #powershell
Publié le 13 février 2026 7 minutes de lecture

Liens utiles

Avant toute chose, cet article est surtout une compilation d’éléments intéressants que j’ai trouvé ailleurs. Voici les principales sources :

Fonctionnement du LM Hash

Utilité de LM Hash

Le LM Hash dans Active Directory est présent pour des raisons de compatibilités avec les versions de Windows antérieures à Windows 2000. C’est une méthode de chiffrement de mot de passe complètement dépassée, autorisée sur les vieux environnements Active Directory pour permettre la cohabitation avec les systèmes obsolètes à l’époque de Windows XP. Le LM Hash comporte plusieurs gros défauts, lié à son âge puisqu’il a été développé dans les années 1980 :

Dans la grande majorité des environnements Active Directory, l’utilisation de LM Hash n’est très probablement plus utile depuis longtemps.

En pratique

Comme d’habitude dès qu’on touche aux mots de passe dans Active Directory, le module DSInternals est obligatoire :

MichaelGrafnetter/DSInternals MichaelGrafnetter/DSInternals

On peut facilement convertir une chaîne de caractère en LM Hash avec la commande ConvertTo-LMHash du module DSInternals. On peut créer un LM Hash de la manière suivante :

'bonjour' | ConvertTo-SecureString -AsPlainText | ConvertTo-LMHash

Sensibilité à la casse

En testant un peu, on peut vérifier que celui-ci n’est en effet pas sensible à la casse. Toutes les versions avec ou sans majuscule d’une même chaîne de caractère donneront toujours le même hash :

Mot de passe LM Hash
bonjour 43d119e8b3d8710baad3b435b51404ee
Bonjour 43d119e8b3d8710baad3b435b51404ee
BONJOUR 43d119e8b3d8710baad3b435b51404ee

Longueur du mot de passe

On remarque également que le découpage en deux blocs est visible, puisque le LM Hash de tous les mots de passe de moins de 7 caractères finissent par aad3b435b51404ee :

Mot de passe LM Hash
bonjour 43d119e8b3d8710baad3b435b51404ee
testing 2d5545077d7b7d2aaad3b435b51404ee
sept c06bd14e029e9e47aad3b435b51404ee

Si on essaye de convertir une chaîne de plus de 14 caractères, on tombe sur l’erreur The password must be 0-14 characters long.

Caractères interdits

Si on utilise des caractères spéciaux non pris en charge comme “€”, on obtient l’erreur Il n’y a pas de caractère correspondant au caractère Unicode dans la page de codes multi-octet cible.

Notes techniques

Autorisation du LM Hash

Le paramètre pour autoriser (ou non) l’utilisation de LM Hash dans le stockage des mots de passe sur Active Directory a maintenant un petit historique :

Pour Windows Server 2025, le paramètre de GPO n’est plus disponible, et même en utilisant la clé de registre DWORD HKLM:\SYSTEM\CurrentControlSet\Control\lsa\NoLmHash définie à 0, ça ne marche pas non plus.

Le paramètre pour le support du LM Hash est le suivant : Computer configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Do not store LAN Manager hash value on next password change. Il faut donc définir ce paramètre à “Désactiver” pour que celui-ci prenne effet (au prochain changement de mot de passe et après redémarrage du contrôleur de domaine).

Création du compte de test

Pour l’occasion, on va créer le compte de test “lmhash” avec un mot de passe de moins de 14 caractères (indispensable pour que le LM Hash puisse être généré) :

New-ADUser -SamAccountName lmhash
Set-ADAccountPassword lmhash -NewPassword ('Password123!' | ConvertTo-SecureString -AsPlainText -Force)

On vérifie maintenant la présence du LM Hash dans la base NTDS avec le module DSInternals :

Get-ADReplAccount -SamAccountName lmhash -Server (Get-ADDomainController)

Après changement de mot de passe

Comme on le sait, le LM Hash ne permet pas de chiffrer des chaines de plus de 14 caractères. Donc si on change le mot de passe de notre compte de test pour Password123456! (15 caractères), le LM Hash disparaît du résultat de la commande Get-ADReplAccount :

Secrets
  NTHash: bee98dc086291586556711a645c6bd58
  LMHash:

Default Domain Password policy incompatible avec LM Hash

Depuis Windows Server 2022, il y a une option pour augmenter la longueur minimum des mots de passe à plus de 14 caractères sur la Default Domain Password Policy. Comme LM Hash ne gère pas ce genre de mot de passe, quel est le comportement du contrôleur de domaine ?

Pour répondre à la question que personne ne se pose, j’ai monté un lab spécialement pour cela ! Voici les différentes étapes :

  1. Augmentation du nombre de caractères minimum à 15 caractères sur la Default Domain Password Policy
  2. Activation du support de LM Hash
  3. Redémarrage du contrôleur de domaine
  4. Création d’un Password Settings Object pour permettre l’utilisation de mots de passe à moins de 14 caractères, ciblé sur le compte “lmhash”
  5. Définition du mot de passe “password” sur le compte “lmhash”

Tout ça pour au final constater que oui, le LM Hash reste présent avec cette configuration.

Plus d’informations sur l’augmentation de la longueur minimum de la Default Domain Password Policy : Audit et application de la longueur minimale du mot de passe sur certaines versions de Windows - Support Microsoft

Cohabitation avec un Windows Server 2025

Dans un domaine avec LM Hash autorisé, comment se comporte un Windows Server 2025 ?

Après avoir passé beaucoup trop de temps à essayer d’intégrer un nouveau contrôleur de domaine sur mon lab parce que je m’étais gouré dans le nom de domaine (corp.contoso.com au lieu de corp.consoto.com), je peux enfin vous donner la réponse !

Voici le comportement d’un Windows Server 2025 dans un domaine avec LM Hash activé :

Si vous souhaitez interdire l’utilisation du LM Hash depuis un serveur en Windows Server 2025+, le paramètre dans la GPMC est introuvable, donc vos meilleures options sont de modifier le paramètre depuis un OS plus ancien ou de venir supprimer la clé de registre directement dans la GPO qui l’autorise :

Chemin : \\corp.consoto.com\SYSVOL\corp.consoto.com\Policies\{votre id de GPO}\Machine\Microsoft\Windows NT\SecEdit

La valeur à supprimer :

[Registry Values]
MACHINE\System\CurrentControlSet\Control\Lsa\NoLMHash=4,0

Et vous voyez par la même occasion que je me suis gouré dans mon nom de domaine à la création de celui-ci…

Comportement de retrait

La suppression du paramètre pour autoriser le LM Hash et le redémarrage des contrôleurs de domaine n’est pas suffisant pour “purger” l’existant. Il va falloir réinitialiser le mot de passe des comptes concernés pour supprimer définitivement le LM Hash de la base NTDS de Active Directory.

Pour lister l’ensemble des comptes qui possède encore un LM Hash enregistré dans la base NTDS :

(Get-ADReplAccount -All -Server (Get-ADDomainController) | Test-PasswordQuality).LMHash
Photo de profil
Article écrit par Léo Bouard

Ingénieur systèmes spécialisé dans les infrastructures, les technologies et l'écosystème Microsoft. Je travaille depuis 2017 sur les questions de gestion d'identité, d'outils collaboratifs et d'automatisation.

Cet article pourrait-il vous intéresser ?