Stockage des hashes LM désactivé dans Active Directory : NoLMHash

Vérifier que le stockage des hashes LM est désactivé dans Active Directory soulève deux questions distinctes : Windows est-il configuré pour ne plus créer de hashes LM des mots de passe, et les mots de passe concernés ont-ils changé depuis l’entrée en vigueur de cette configuration ? Une stratégie de mot de passe plus forte ou un paramètre réseau NTLMv2 ne suffit pas, à lui seul, à répondre aux deux questions.

Ce guide explique le contrôle de stockage Microsoft, trois vérifications de configuration documentées et un plan de remédiation progressif. Il expose aussi explicitement une limite du produit : le contrôle EtcSec nommé ANSSI_R23_LM_HASH_NOT_DISABLED évalue LmCompatibilityLevel, et non NoLMHash. Son résultat ne constitue pas un inventaire des secrets LM stockés.

Stockage des hashes LM dans Active Directory : que signifie sa désactivation ?

Microsoft distingue deux représentations des mots de passe : l’ancien hash LM et le hash NT. Elles peuvent résider dans la base locale Security Accounts Manager (SAM) ou dans Active Directory. La représentation LM est plus faible et plus vulnérable à la récupération hors ligne des mots de passe. La KB 299656 de Microsoft sur la prévention du stockage des hashes LM décrit la génération historique de données LM pour les mots de passe de moins de 15 caractères.

Cette description historique ne permet pas d’affirmer que toute installation Windows actuelle crée des hashes LM pour les mots de passe courts. La référence Microsoft de la stratégie de stockage indique des valeurs effectives par défaut activées pour les rôles système de son tableau, tandis que les entrées des GPO par défaut du domaine et des contrôleurs de domaine sont non définies. Il s’agit de valeurs par défaut documentées, pas d’observations de votre domaine.

La stratégie de stockage agit au changement de mot de passe. Un compte dont le mot de passe est antérieur au déploiement effectif doit donc figurer sur une liste de revue. Cette déduction est conditionnelle et découle du moment où la stratégie agit : l’ancien mot de passe a peut-être déjà évité des données LM utilisables grâce à sa longueur, à une configuration antérieure ou au comportement du système d’exploitation. L’ancienneté du mot de passe ne prouve à elle seule ni leur présence ni leur absence.

Cet article se concentre sur le stockage LM et le renouvellement. Les autres indicateurs relatifs aux mots de passe et les dépendances des services sont traités dans Sécurité des mots de passe Active Directory et hygiène des comptes de service. Utilisez ce guide pour la revue globale des comptes ; conservez ici une décision de clôture distincte pour la question du stockage.

Fonctionnement : hashes stockés et réponses réseau relèvent de contrôles distincts

La procédure de stockage Microsoft documente NoLMHash comme une valeur DWORD définie à 1 sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa pour Windows XP et Windows Server 2003. Sa procédure pour Windows 2000 SP2 et versions ultérieures utilise une clé à la place. Ces procédures historiques de registre exigent un redémarrage et diffèrent dans leur traitement de l’historique des mots de passe ; ne généralisez pas leurs détails de purge d’une version à l’autre. La KB 299656 décrit aussi les mots de passe d’au moins 15 caractères comme produisant une valeur LM inutilisable pour l’authentification. Augmenter la longueur minimale dans une stratégie ne démontre pas qu’un ancien mot de passe a été renouvelé. Voir les méthodes Microsoft propres à chaque version.

La valeur indépendante LmCompatibilityLevel contrôle le comportement d’authentification réseau. Le tableau suivant reformule la référence Microsoft du niveau d’authentification LAN Manager. Ici, NTLMv1 désigne la variante NTLM historique dans le tableau Microsoft.

Le niveau 3 modifie les réponses du client sans imposer le refus côté serveur du niveau 5. Le niveau 5 autorise toujours NTLMv2 et n’efface pas les secrets des bases de données. Traitez le durcissement réseau et la suppression du stockage comme des tâches distinctes.

Guide ANSSI connexe : Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory. Le contrôle de stockage LM décrit ici est documenté par Microsoft.

Détection : recueillir les preuves de configuration et de renouvellement

Les commandes ci-dessous sont des exemples adaptés de la documentation Microsoft. Elles n’ont pas été exécutées dans un environnement Active Directory client. Exécutez chaque mesure séparément sur le système Windows concerné et conservez son identité, l’horodatage, la sortie et toute erreur.

1. Examiner la valeur du contrôle de stockage

Cette commande combine la syntaxe reg query de Microsoft avec le chemin et la valeur de la KB 299656 :

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v NoLMHash

Recherchez la valeur DWORD documentée 0x1 lorsque la procédure DWORD s’applique. La requête lit la configuration locale, pas les données de mots de passe SAM ou AD. Une valeur absente ou une requête en échec doit être interprétée en fonction du système d’exploitation et de la stratégie effective. Cela ne prouve pas l’existence d’un hash LM. Microsoft documente le code de retour 0 pour une requête de registre réussie et 1 pour un échec.

2. Examiner séparément la valeur du contrôle réseau

Cette commande utilise la même syntaxe de requête et l’emplacement dans le registre de la stratégie d’authentification :

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel

Consignez cette valeur dans un champ différent de NoLMHash. Une valeur réseau de 0x5 ne prouve ni la suppression du stockage ni le renouvellement des mots de passe. Séparer les deux lectures facilite aussi l’analyse d’un résultat inattendu du collecteur.

3. Produire le rapport de stratégie ordinateur

La référence Microsoft de gpresult documente la portée ordinateur et la sortie HTML :

gpresult /scope computer /h lm-policy.html

Examinez le rapport de stratégie ordinateur obtenu avec les lectures du registre. Microsoft documente une exigence SysWow64 pour les rapports HTML sur ARM64 et des exigences de pare-feu pour les rapports à distance. L’exemple local ci-dessus évite les paramètres de cible distante. Un rapport de stratégie fournit le contexte de configuration ; il n’examine pas les hashes stockés.

Constituer une liste de candidats sans exagérer la portée du signal

Comparez les dates de renouvellement des mots de passe des comptes aux dates vérifiées de déploiement de la stratégie de stockage. Lorsque les dates de déploiement effectif diffèrent, conservez cette incertitude au lieu d’attribuer une date unique commode à tout le domaine. Cette comparaison est une méthode de revue déduite du comportement au prochain changement, pas un détecteur direct de LM ni un constat mesuré dans votre environnement.

Remédiation : supprimer le stockage, puis renouveler les mots de passe concernés (Remediation)

1. Identifier les dépendances et désigner les responsables

Avant toute modification, établissez une liste délimitée des DC, des versions Windows applicables et des comptes à examiner. Ajoutez les systèmes concernés par les comptes locaux si le stockage SAM local fait partie de la mission. Désignez un responsable pour chaque changement de compte de service et un responsable de la vérification de la distribution de la stratégie.

Les références Microsoft sur le stockage et l’authentification décrivent des effets sur la compatibilité des clients anciens et de certaines applications. Appuyez-vous sur cet avertissement pour planifier les tests des dépendances réelles de votre parc. Il ne prouve pas qu’une application particulière exige encore LM. Consignez une dépendance seulement après son identification par le responsable ; évitez de transformer une inquiétude non testée en exception permanente.

2. Activer la stratégie de stockage Microsoft

Dans les options de sécurité de l’ordinateur, activez « Network security: Do not store LAN Manager hash value on next password change ». Microsoft situe cette stratégie sous la configuration ordinateur, les paramètres Windows, les paramètres de sécurité, les stratégies locales et les options de sécurité. La page de la stratégie de stockage indique qu’aucun redémarrage n’est requis pour cette stratégie.

Si une procédure de registre propre à une version est nécessaire, suivez les instructions applicables de la KB 299656, y compris ses consignes de sauvegarde du registre. Sa séquence historique XP/Server 2003 comprend un redémarrage suivi d’un changement de mot de passe. Ne confondez pas cette séquence avec le comportement distinct de redémarrage indiqué sur la page de la stratégie.

3. Confirmer la distribution effective avant de prévoir la clôture

Répétez les trois mesures de détection sur chaque DC concerné et chaque système applicable de comptes locaux. Conservez ensemble le rapport et les lectures du registre. Pour chaque système, consignez une date effective vérifiée ou indiquez que cette date reste indéterminée.

N’utilisez pas la présence d’une seule GPO conforme comme critère d’acceptation du déploiement. L’implémentation du collecteur présentée plus bas peut réussir dès qu’une GPO inventoriée contient le niveau réseau, sans prouver la couverture. Le dossier de remédiation doit donc préciser quels systèmes ont été vérifiés directement et lesquels restent non vérifiés.

4. Organiser le renouvellement des mots de passe avec les responsables des services

Le guide Microsoft de la stratégie de stockage demande aux utilisateurs de définir de nouveaux mots de passe à leur prochaine connexion au domaine. Planifiez le renouvellement correspondant des comptes après l’entrée en vigueur du contrôle de stockage.

Pour les comptes qui ne se connectent pas régulièrement, attribuez une tâche explicite de renouvellement au lieu d’attendre une connexion utilisateur ordinaire. Pour les comptes de service, coordonnez les services dépendants, les tâches planifiées et les applications avec leurs responsables. La séquence pratique doit identifier le compte, préparer les mises à jour des dépendances, réaliser le changement approuvé, tester le service et conserver le résultat. Il s’agit d’un plan opérationnel de déploiement, pas d’une affirmation qu’une rotation massive a été réalisée.

Un problème connexe de cycle de vie est expliqué dans Fallback Kerberos RC4 et génération des clés AES dépendante du mot de passe. La leçon commune de planification est d’inclure le renouvellement des comptes dans les projets de configuration. La génération des clés AES et la suppression de LM restent des mécanismes différents, avec des exigences de validation différentes.

5. Traiter le durcissement réseau comme un changement à part entière

Sélectionnez et testez séparément le niveau réseau LAN Manager prévu, en utilisant les consignes de compatibilité Microsoft. Ne considérez pas la réussite d’un déploiement du niveau 5 comme la clôture du nettoyage du stockage LM.

Conservez la négociation NTLMv1, les protections contre le relais, l’exposition mémoire WDigest et les restrictions NTLM sortantes de Tier 0 dans leurs chantiers existants. Répéter ces projets ici masquerait le livrable manquant : un déploiement documenté de la stratégie de stockage suivi du renouvellement des comptes dans le périmètre.

Validation : clôturer la revue avec un dossier de preuves délimité

Utilisez un dossier de clôture qu’un second administrateur puisse comprendre sans reconstituer le projet à partir de conversations ou de captures d’écran. Voici un format de preuves suggéré ; ce n’est ni un schéma de sortie Windows ni une attestation d’examen des secrets.

Formulez la conclusion au niveau que les preuves permettent d’étayer. Par exemple, un dossier peut établir que le paramètre de stockage prévu a été vérifié sur les DC listés et que les comptes listés ont été renouvelés ensuite. Il ne doit pas étendre cette affirmation aux comptes non examinés, à l’historique des mots de passe de toutes les versions Windows ou à un inventaire de tous les secrets stockés.

Relancez les vérifications de configuration après le changement et faites le point sur les systèmes ou comptes restants. Rendez visibles les preuves incomplètes : un DC inaccessible, un service non testé ou une date de renouvellement inconnue doit avoir un responsable et une prochaine action.

Comment EtcSec détecte cette situation

Le code actuel d’etc-collector fournit deux contrôles connexes de stratégie réseau. Aucun ne lit NoLMHash ni n’inventorie les secrets LM dans SAM ou AD. L’analyse suivante est une revue statique du code au commit du collecteur b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c ; ce n’est pas un résultat d’audit client.

ANSSI_R23_LM_HASH_NOT_DISABLED

Malgré son identifiant historique et son libellé de catalogue orienté stockage, ce détecteur évalue LmCompatibilityLevel. Dans internal/audit/detectors/ad/compliance/anssi/anssi-r23-lm-hash-not-disabled.go:17, la boucle aux lignes 30–43 ignore les stratégies ou paramètres nil et considère la condition satisfaite dès qu’une quelconque GPO inventoriée possède une valeur définie supérieure ou égale à 5.

Il renvoie Count = 0 lorsque cette condition est satisfaite, et Count = 1 sinon, y compris si l’ensemble de stratégies est vide ou si les valeurs sont absentes. L’implémentation ne calcule pas la priorité effective des GPO et ne prouve pas la couverture de chaque DC ou OU. Elle utilise aussi un seuil numérique au lieu de valider la plage 0–5 documentée par Microsoft : une valeur collectée de 6 satisferait la comparaison, sans devenir pour autant un niveau Windows documenté.

La condition décisive dans le code est :

if p.RegistrySettings.LmCompatibilityLevel != nil &&
    *p.RegistrySettings.LmCompatibilityLevel >= 5 {
    compliant = true
    break
}

Il s’agit d’un extrait mis en forme des lignes 35–38, pas d’un programme autonome. Un décompte égal à zéro signifie que cette condition de stratégie réseau a été trouvée dans les données fournies. Il ne confirme ni la suppression du stockage, ni le renouvellement des comptes, ni un durcissement réseau complet ; le détecteur ne vérifie pas les paramètres de sécurité minimale des sessions NTLM.

NTLMV1_ALLOWED

Le détecteur voisin dans internal/audit/detectors/ad/gpo/ntlmv1-allowed.go:22 lit le même champ aux lignes 32–34. Les lignes 37–38 définissent Count = 1 lorsque la valeur sélectionnée est absente ou inférieure à 5 ; sinon le décompte reste à zéro.

La sélection diffère. La fonction auxiliaire internal/audit/helpers/gpo_policy.go:130 recherche d’abord une valeur définie dans la stratégie par défaut des DC, puis dans la stratégie par défaut du domaine, puis dans une autre stratégie. C’est la règle de sélection de cette fonction, pas un calcul complet de la stratégie résultante Windows.

Ces contrôles peuvent donc diverger. Dans une entrée hypothétique avec une stratégie par défaut des DC à 3 et une autre GPO à 5, le contrôle portant le nom ANSSI renvoie zéro tandis que NTLMV1_ALLOWED renvoie un. Cet exemple découle de la logique du code ; aucune configuration client de ce type n’a été observée.