Dans un environnement Windows, il existe deux familles de protocoles d'authentifications natives permettant de gérer l'accès aux ressources. Les protocoles Lan Manager, NTLM et Kerberos. L'apparition du protocole LanManager remonte aux années 80, il y a presque 40 ans. Il est très ancien et très vulnérable. NTLM son successeur est apparu quelque temps après et la version actuel NTLMv2 date de Windows NT4 SP4. Kerberos est le protocole par défaut dans les domaines Active Directory. Son fonctionnement est très différent de NTLM et assure un bon niveau de sécurité. Il continue d'évoluer et à partir Windows Serveur 2012 il est possible de renforcer les flux réseaux.
S'il est recommandé de privilégier Kerberos, il reste difficile de se séparer complètement de NTLM dans un domaine AD ( beaucoup d'applications l'utilisent encore). Malgré son âge, NTLM V2 reste un protocole acceptable avec certaines limites pour les comptes à haut privilège et en mettant en place une stratégie de mot de passe suffisamment complexe. Les versions LanManager et NTLM V1 devrait être désactivé.
Certains paramètres permettant la compatibilité avec d'anciens systèmes, existent toujours dans les versions récentes de Windows.
Cependant, les valeurs par défaut de ces paramètres ont pu évoluer afin de rédduire les vulnérabilités. C'est le cas, lorsque vous installez un nouveau domaine, alors qu'un domaine migré peut rester vulnérable même avec des contrôleurs de domaine récents.
Dans un environnement en groupe de travail, Kerberos n'est pas disponible. De même lorsque vous accédez à un service avec un compte local à la machine, seul le protocole NTLM est utilisé. Idem, en utilisant l'adresse IP, NTLM sera systématiquement utilisé.
L'image ci-dessous présente de manière très synthétique, les principes d'authentification avec LM,NTLM, NTLM V2.
Dans l'étape « 1 », le client ouvre sa session en utilisant son compte et son mot de passe. Le client Windows génère le NTHash et le conserve en mémoire. Le mot de passe peut également être retrouvé sur l'ordinateur au niveau de la mise en cache dans la partie du registre accessible que par le système( afin d'assurer une ouverture de session hors connexion).
Lorsqu'un client veut se connecter à un serveur (2), il envoie une requête au serveur de destination avec le nom du compte et le serveur lui répond en lui demandant de répondre à un challenge.
Le client répond au défi (3) en codant le Hash du mot de passe et un code aléatoire transmis par le serveur.
Le serveur transmet les éléments au contrôleur de domaine, s'il s'agit d'un compte du domaine. Ce dernier va valider ou non l'authentification de l'utilisateur (4).
Les condensats (Hash du mot de passe) ne sont pas générés de la même manière entre LanManaget (LMHash) et NTLM (NTHash). Les hash LM sont très anciens et extrêmement fragiles. La taille du mot de passe est de 14 caractères au maximum. Il n'est pas sensible à la casse et tous les caractères sont convertis en majuscules. Il est codé par bloc de 7 caractères et il est très simple de déterminer si le mot de passe est vide ou s'il ne dépasse pas les 7 caractères, car dans ce cas une séquence bien connue est identifiable. Je ne vais pas détailler plus cette partie, il est juste important de retenir que les Hash de mots de passe LanManager ainsi que le protocole d'authentification (flux réseaux) correspondant ne devraient plus être utilisé de nos jours.
Depuis Windows Vista et Windows Server 2008, le comportement par défaut est de ne plus stocker le condensat LM, mais il est possible de le faire en modifiant des paramètres et ceux même sur des versions récentes de Windows Server.
L'utilisation de NTLM reste sensible a tous les niveaux, du poste client (HashNT dans le cache et dans la mémoire), du serveur et du contrôleur de domaine, mais également dans les flux réseaux.
Il est recommandé de désactivé LM et NTLM V1 et de limiter l'usage des protocoles NTLM V2 pour les comptes à fort privilège comme par exemple les comptes d'administrations d'Active Directory. Vous pouvez consulter l'article suivant sur le groupe « Protected Users » apparu dans Windows Server 2012.
Il existe un paramètre de stratégie de groupe indiquant aux serveurs de ne plus stocké de condensat LanManager (LMHash). Il est recommandé d'activer cette option.
Configuration ordinateur\ Paramètres Windows\ Paramètres de sécurité\ Stratégies locales\Options de sécurité\ Sécurité réseau
Sécurité réseau : ne pas stocker de valeurs de hachage de niveau LAN Manager sur la prochaine modification de mot de passe Activé
La règle ne sera appliquée qu'au prochain changement de mot de passe.
Un autre paramètre est important dans un domaine. Il s'agit du paramètre « Niveau d'authentification LAN Manager » :
Sécurité réseau : niveau d'authentification LAN Manager (LMCompatibilityLevel).
Il permet de configurer l'utilisation des protocoles par les clients et les serveurs. Il est d'autant plus important qu'il s'agit d'un des paramètres les moins bien compris. Vous trouverez les détails sur les 5 niveaux possibles de ce paramètre.
Les niveaux 1 à 3 correspondent au comportement d'un poste lorsqu'il agit en tant que client et même s'il s'agit d'un OS serveur. Les niveaux 4 et 5 fonctionnent comme le 3 au niveau client mais modifie le comportement lorsqu'il agit en tant que serveur . Par exemple depuis un serveur membre ou en workgroup vous essayer d'accéder à un partage sur un poste client avec son adresse IP (donc pas de Kerberos). Le poste client fait office de serveur pour ce partage, alors que le serveur fait office de client. Si le niveau du poste client est de 5, il n'acceptera de répondre qu'aver NTLM V2.
Il est conseillé sauf si vous avez des systèmes anciens et/ou non compatibles d'utiliser à minima le niveau 3 (client envoie les demandes en NTLM V2) et il préférable d'utiliser le niveau 5 (le serveur ne répond qu'avec NTLM V2). Cequi nous donne :
Sécurité réseau : niveau d'authentification LAN Manager Envoyer uniquement une réponse NTLM version 2. Refuser LM et NTLM
Un autre élément important à connaître, est la sécurité de Session NTLM 2 qui peut vous induire en erreur sur le fonctionnement de ce paramètre. Je vous laisse lire cet article, pour plus de détail :
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc160954(v=msdn.10)
Il est donc recommandé de positionner ces deux paramètres :