NTLM est l'évolution du protocole Lan Manager. La première version de NTLM date de 1993 avec Windows NT 3.1. La version NTLM V2 quant à elle date de 1996 et Windows NT 4.0 SP4.
Dans un domaine Active Directory, le protocole Kerberos est privilégié pour l'authentification depuis Windows 2000. Néanmoins il reste des situations où le système utilise NTLM plutôt que Kerberos. C'est le cas par exemple lorsque vous utilisez des comptes locaux plutôt que des comptes de l'annuaire ou que vous êtes en groupe de travail sans domaine Active Directory.
C'est également le cas lorsque vous accédez à une ressource sur le réseau en utilisant une adresse IP plutôt que le nom du serveur.
Avec Kerberos, le client demande au contrôleur de domaine un ticket pour accéder à une ressource, le ticket contient le nom du service en question (généralement avec le nom du serveur ou un alias). Si ce nom de connexion ne figure pas dans le Service Principal Name du compte de l'ordinateur ou du compte de service de l'application, alors Kerberos ne fonctionnera pas et NTLM sera utilisé. C'est le cas pour l'adresse IP par exemple qui ne figure pas dans les SPNs.
De plus, pour utiliser Kerberos le poste client doit pouvoir contacter un contrôleur de domaine, ce qui n'est pas toujours évident si vous travaillez à l'extérieur de l'entreprise.
Il est possible d'utiliser pour certaines applications une délégation pour autoriser un service à chercher des tickets Kerberos pour vous, ou utiliser un autre protocole comme NTLM.
Je ne vais pas détailler la délégation Kerberos dans cet article, mais juste pour vous donner une idée, vous avez mis en place un serveur Web avec une application. Vous souhaitez que l'utilisateur se connecte à l'application avec ses identifiants Windows et privilégie Kerberos à NTLM. Il vous faudra déléguer le droit à votre serveur WEB d'obtenir les tickets Kerberos en votre nom. L'application doit être configuré pour prendre en charge les délégations Kerberos.
La délégation se configure sur les propriétés du compte depuis la console « utilisateurs et ordinateurs Active Directory » :
Les noms de services (SPN) sont configurés dans un attribut AD du compte de service ou du compte de l'ordinateur :
Vous trouverez deux exemples dans les liens suivants sur Kerberos et la configuration des SPNs : [AD DS Sécurité] Principe de l'authentification Kerberos , https://learn.microsoft.com/fr-fr/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections?view=sql-server-ver16.
Si vous n'avez pas réalisé ce type de configuration, il est fort probable que vous utilisiez NTLM plutôt que Kerberos.
Le sujet de la sécurité et de l'utilisation de NTLM est présent depuis plusieurs années. Je vous renvoie sur cet article LMComptibilityLevel et sur un article de Microsoft qui parle du niveau d'authentification Lan Manager (NTLM est l'évolution de LAN Manager) comme étant le paramètre de Windows le plus mal compris de tous les temps.
Si vous suivez les publications de Microsoft peut-être avez-vous déjà lu l'article récent (21/09/2023) sur le renforcement de la sécurité d'Active Directory : Active Directory Hardening Series - Part 1 – Disabling NTLMv1. Un article récent, pour un sujet qui a déjà plusieurs années.
Comme le rappel l'article, NTLM n'envoie pas de mot de passe en clair et utilise le principe d'un défi réponse. Le client répond en codant le défi par le Hash du mot de passe de l'utilisateur. La principale différence entre NTLM V1 et NTLMv2 est l'utilisation d'algorithme de chiffrement différent. Si NTLM v1 utilise un chiffrement basé sur DES qui n'est plus considéré comme sécurisé depuis quelques années déjà, NTLM V2 utilise HMAC-MD5 nettement meilleur, mais également insuffisant.
En conclusion, NTLM n'est plus suffisamment sécurisé. La solution est simple, il suffit de le désactiver NTLM et d'utiliser Kerberos. Il y a d'ailleurs des paramètres de GPO qui permettent cela :
|
|
Lisez la suite avant de tester le paramètre dans une GPO sur votre environnement. |
Les paramètres de GPO sont apparus sous Windows 7 et Windows Server 2008 R2. Vous trouverez plus d'information sur ces éléments dans l'article suivant : https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/jj865674(v=ws.10). L'article date de 2012, il y a plus de 10 ans.
On retrouve d'ailleurs un autre article remis à jour en 2019, https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/ntlm-blocking-and-you-application-analysis-and-auditing/ba-p/397191 qui explique la méthodologie pour auditer l'usage de NTLM dans le domaine Active Directory.
L'article essaie de nous rendre attentifs sur l'importance de la phase d'audit. On nous explique qu'un déploiement des paramètres de blocage des authentifications NTLM dans le domaine, prend au moins 6 mois.
Pour ma part, j'essaie de vous rendre attentif sur les situations pour lesquelles vous êtes encore dépendant de NTLM. Nous verrons dans un prochain article que Microsoft va apporter des changements significatifs à ces questions dans les prochaines versions de Windows 11.
On approche de la fin de vie de NTLM ? Bon après tout cela fait déjà plus de 10 ans que la communication existe sur la sécurité et la désactivation de NTLM …
Pour finir sur les questions de sécurités, si la sécurité de NTLM est devenue insuffisante, en utilisant des niveaux de chiffrement faible, que dire des connexions LDAP avec authentification simple. En effet dans AD DS, il y a Kerberos et NTLM, mais pas que …
AD DS est une implémentation d'un annuaire LDAP proposé par Microsoft. Dans LDAP, on retrouve également des services d'authentification. Parmi les méthodes d'authentification, on retrouve par exemple la méthode d'authentification simple consistant à envoyer un compte et un mot de passe en texte clair sur le réseau. Si DES n'est pas suffisant pour chiffrer le mécanisme d'authentification, que dire du mot de passe en texte clair.
Vous pouvez trouver ce type d'authentification sur votre copieur multifonction qui va interroger l'annuaire afin d'obtenir la liste des adresses de messagerie de vos utilisateurs. Admettons vous avez configurer votre copieur dernière génération pour utiliser une l'authentification simple vers l'annuaire (c'est souvent le paramètre par défaut). Pour simplifier la maintenance, vous conservez le mot de passe du fabricant pour accéder à la page d'administration de votre copieur. Imaginez la suite… Quelques outils suffiront à définir le chemin pour compromettre votre domaine.
Vous pouvez également voir ce type d'authentification dans diverses applications ou des outils de gestion d'identification Web comme KeyCloak par exemple. Par défaut, l'authentification simple sur LDAP est disponible sur les contrôleurs de domaine Active Directory si vous n'activez pas la signature LDAP. Il vous est également possible d'utiliser LDAP sur le port 636 avec SSL (enfin TLS aujourd'hui).
Pour Microsoft choisir de bloquer ce type d'authentification unilatéralement représente le même défit que d'interdire NTLM. L'activation de ce paramètre avait d'ailleurs initialement était prévue dans les mises à jour en 2020, avant de revenir sur cette décision.
Le changement ne peut passer que par un audit et un plan d'action propre à chaque environnement. Je vous mets les liens sur mes articles précédents concernant ce sujet :
[AD DS Security] Sécurité des connexions LDAP (partie 1)
[AD DS Security] Sécurité des connexions LDAP (partie 2)
[AD DS Security] Sécurité des connexions LDAP et SSL (partie 3)
