De NTLM à Kerberos : sacré chantier pour Microsoft

Exit NTLM, place à Kerberos ? L’objectif est clair ; l’exécution, pas si évidente.

En façade, Microsoft vient de franchir une étape : il a ajouté NTLM à la liste des fonctionnalités obsolètes de Windows (client et serveur). En back-office , il mène des travaux d’extension de Kerberos, pas encore adapté à tous les scénarios d’authentification.

La version la plus récente de NTLM (v2) était arrivée avec Windows 2000. Il s’agit d’un protocole classique de type challenge-and-reponse : le serveur demande au client de s’authentifier et celui-ci lui répond avec un message chiffré contenant nom d’utilisateur + mot de passe.

Problème : NTLM repose sur de la cryptographie aujourd’hui considérée comme fragile. Pas tant au niveau au niveau de la fonction de hachage HMAC-MD5 qu’au niveau de l’algorithme sur lequel elle s’appuie. En l’occurrence, MD4, dont l’entropie est relativement basse. L’absence de salage du mot de passe ajoute aux risques de sécurité : le paquet peut être intercepté… et, par exemple, réutilisé dans des attaques de type pass-the-hash.

Autre limite de NTLM : le client n’a pas moyen d’authentifier le serveur. Un vecteur d’attaques par relais, où un serveur malveillant s’insère au milieu d’une connexion.

Enfin, les mots de passe sont le seul format d’authentifiant que supporte NTLM. Pas de certificats, de biométrie, de clés FIDO, etc.

Adapter Kerberos…

De longue date, Microsoft appelle à utiliser l’interface Negotiate (ou SPNEGO). Avec elle, client et serveur s’accordent sur la meilleure solution d’authentification à utiliser. Par défaut Kerberos ; sinon, on bascule sur NTLM.

Intégré à Windows en l’an 2000, Kerberos emploie une cryptographie plus robuste que NTLM, gère l’authentification serveur et une plus grande variété d’authentifiants. L’une de ses particularités et de nécessiter un KDC (centre de distribution de clés). Celui-ci délivre des tickets qui permettent d’en obtenir d’autres au niveau des serveurs d’applications.

Le client doit impérativement avoir le KDC en ligne de mire (line of sight). Dans la pratique, ce n’est pas toujours le cas, que ce soit en raison d’une topographie complexe, de règles de pare-feu ou d’une localisation hors du réseau d’entreprise. Face à cet écueil, Microsoft mise sur AIKerb. Avec cette solution, les messages sont envoyés directement au serveur d’application… qui, lui, a le KDC en ligne de mire. Une forme de proxy que Microsoft tente de standardiser pour en faire une extension officielle à Kerberos (RFC 4120). Et permettre ainsi aux tierces parties (Samba, Apple…) une interaction plus simple.

Autre cas qui nécessite d’adapter le protocole : les utilisateurs locaux, authentifiés directement par le serveur d’application. La solution : des KDC locaux, sur chaque machine Windows, de sorte qu’elles peuvent gérer des messages Kerberos en lien avec l’autorité de sécurité locale.

… et gérer les exceptions NTLM

Grâce à ces deux techniques, on couvre environ un tiers des fallbacks NTLM, assure Microsoft.

Des solutions, il y en a aussi pour les quelque 15 % de fallbacks qui entrent dans la catégorie « serveur inconnu ». Pour environ moitié, il s’agit de cas, où le serveur utilise une adresse IP. Par défaut, Kerberos refuse la connexion. Pour l’autre moitié, le serveur a un nom mal configuré : lorsqu’on demande un ticket, on envoie au contrôleur de domaine un nom qu’il ne comprend pas… ce qui entraîne le basculement vers NTLM.

Microsoft reconnaît que dans le deuxième cas, il ne peut rien faire : c’est un problème de sécurité. Dans le premier : il existe des clés de registre et des stratégies permettant de contrôler si une IP peut être utilisée pour Kerberos.

Le reste des fallbacks (environ 50 %) est lié aux applications qui codent en dur l’usage de NTLM. À ce niveau, il est impensable d’agir « à la volée ». En adaptant ses propres applications (spouleur d’impression, services RPC…), Microsoft parvient tout de même à couvrir, au global, 80 % des fallbacks.

Hors de Windows, l’inconnue ou presque

IAKerb et Local KDC seront livrés en tant que sous-protocoles au sein de SPNEGO. Microsoft ne cache pas qu’il y aura du travail pour l’authentification avec des systèmes autres que Windows. En attendant, il promet divers outils aux administrateurs, dont des options de configuration d’IAKerb par appareil et par service.

Quant à supprimer NTLM ou même le désactiver par défaut on n’y est pas encore. Aux dernières nouvelles, le protocole continuera à fonctionner dans la prochaine version de Windows Server (2025) et la prochaine mise à jour annuelle de Windows (10 et 11).

Illustration générée par IA