Guide pour éliminer complètement NTLM de votre environnement

Résumé

L’élimination de NTLM d’un environnement d’entreprise est une défi importantIl est profondément ancré dans de nombreuses infrastructures et, dans certains cas, des applications critiques existantes en dépendent encore. Remplacer ces applications peut sembler irréaliste, et c'est la raison pour laquelle, depuis des années, NTLM est resté en usage. Mais la réalité est différente : la plupart des organisations n’ont pas réellement besoin de NTLM, et le plus gros obstacle est que l’activité NTLM est difficile à détecter à l’intérieur Active DirectoryCette difficulté ne fait que croître à mesure que l’environnement évolue. 

Considérant le Fin de vie de Windows 10, parallèlement à l'annonce par Microsoft de l'abandon de NTLM, ce problème a refait surface. Les organisations doivent commencer à se demander : comment fonctionnerons-nous sans NTLM ? protocoles d'authentification, et quelles mesures devrions-nous prendre maintenant pour nous préparer ? 

NTLM n'est pas une fatalité : il peut être modifié. Ce guide explique son fonctionnement. Active Directory, pourquoi il peut être difficile de l'éliminer progressivement, et fournit un plan pratique que vous pouvez suivre pour détecter et éliminer l'utilisation de NTLM dans votre organisation.

Partie 1 : Comment fonctionne NTLM ?

NTLM (NT LAN Manager) est l'un des plus anciens protocoles d'authentification de Microsoft, initialement conçu pour les premiers réseaux Windows. Il a été conçu pour permettre aux utilisateurs de prouver leur identité sans envoyer de mot de passe en clair, en s'appuyant sur un mot de passe. mécanisme de défi-réponseBien que cette mesure ait été efficace dans les années 1990, elle est aujourd’hui considérée comme obsolète et peu sûre selon les normes actuelles.  

Le processus d'authentification NTLM suit un échange de trois messages entre le client, le serveur et le contrôleur de domaine : 

1. Négocier NTLM 
   Le client lance l'authentification en envoyant un message « Négocier » au serveur. Ce message détaille les fonctionnalités du client, notamment les versions NTLM prises en charge. 

2. Défi NTLM 
   Le serveur répond par un message « Challenge » contenant un nonce de 16 octets généré aléatoirement (le défi). Cela garantit que les tentatives d'authentification ne peuvent pas être répétées. 

3. Authentification NTLM 
   Le client prouve maintenant son identité en générant une réponse à l’aide du hachage de mot de passe stocké. 

• L'étape critique : le le client calcule la réponse du défi NTLM selon les critères du serveur (par exemple, NTLMv1 ou NTLMv2). 

• Avec NTLMv1, le client crypte le défi à l'aide de DES, qui est faible et facilement forcé. 

• Avec NTLMv2, le client inclut des données supplémentaires, telles qu'un horodatage et un nonce client, ce qui produit une réponse plus fiable, mais toujours imparfaite. Le client renvoie cette réponse au serveur dans un message « Authentifier ». 

4. Accepter ou rejeter 
   In Active DirectoryLe serveur transmet le défi et la réponse au contrôleur de domaine. Ce dernier recherche le hachage du mot de passe de l'utilisateur stocké dans Active Directory, effectue le même calcul et compare les résultats. Si les résultats correspondent, l'authentification est acceptée ; sinon, elle est rejetée. 

Bien que Kerberos a longtemps été la méthode d'authentification préférée dans Active DirectoryNTLM est encore largement utilisé. Souvent, les applications y recourent en cas de défaillance de Kerberos. Ce comportement de repli est l'une des principales raisons pour lesquelles il est difficile d'éliminer NTLM : les administrateurs peuvent même ignorer que NTLM est toujours actif dans leurs environnements. 

Partie 2 : Éliminer NTLM dans votre organisation

La suppression de NTLM ne se résume pas à un simple changement de configuration : c'est un processus qui exige visibilité, planification et exécution rigoureuse. L'essentiel est de commencer par identifier les domaines dans lesquels NTLM est encore utilisé, puis de réduire progressivement sa dépendance, et enfin de le supprimer complètement. 

Étape 1 : Déterminer quelles applications utilisent NTLM

On ne peut pas éliminer ce qu'on ne voit pas. La première étape consiste à détecter l'utilisation de NTLM dans votre environnement. 

Mapper manuellement les applications NTLM n'est pas chose aisée. Cela nécessite de parcourir les journaux d'événements Windows (par exemple, les ID d'événement 4624 (connexion réussie) et 4776 (authentification NTLM)) et d'activer les stratégies d'audit NTLM via la stratégie de groupe. Bien que possible, cette opération est chronophage et devient encore plus complexe dans les environnements de grande taille. 

Au lieu de cela, moderne sécurité d'identité les fonctionnalités vous permettent de compiler toutes les instances d'utilisation NTLM dans votre environnement dans une seule vue. 

Dans l' Silverfort plate-forme, voici comment vous créeriez un rapport complet de toutes les applications utilisant NTLM dans votre environnement : 

1. Ouvrez l'onglet Journaux d'authentification 

2. Créer un filtre de protocole NTLM 

• Ajoutez des filtres supplémentaires selon vos besoins (plage horaire, utilisateurs, appareils, etc.)
• NTLMv1 peut être filtré directement en appliquant l'indicateur de risque

3. Exporter le rapport

• Regroupez les données par destination pour identifier les applications et les serveurs qui utilisent encore NTLM

Il est important de garder à l'esprit que le client est responsable du calcul NTLM. Cela signifie que les efforts de détection ne peuvent pas s'arrêter au niveau de l'application ; vous devez également identifier les clients qui basculent vers NTLM. Pour éliminer complètement NTLM, vous devez surveiller en permanence les clients et détecter les raisons de ce basculement. Dans de nombreux cas, ce basculement se produit lorsque Kerberos ne peut pas être établi ; par exemple, en raison de noms principaux de service (SPN) mal configurés ou lorsqu'un client se connecte à une ressource en utilisant une adresse IP au lieu d'un nom d'hôte NetBIOS ou DNS, comme l'exige Kerberos. Vous devez traiter ces causes sous-jacentes pour éviter que les clients basculent par défaut vers NTLM. 

Lors de l'analyse des échecs d'authentification Kerberos, n'oubliez pas que, dans la plupart des cas, un échec Kerberos est immédiatement suivi d'une authentification NTLM réussie. Ce comportement facilite la persistance silencieuse de NTLM dans l'environnement. Chaque échec Kerberos doit donc être analysé afin d'en comprendre la cause sous-jacente, qu'il s'agisse d'un nom principal de service (SPN) manquant ou mal configuré, de l'utilisation d'adresses IP au lieu de noms d'hôtes ou d'autres erreurs d'implémentation. Sans cette analyse, le repli NTLM persistera sans contrôle, compromettant ainsi les efforts visant à l'éliminer. 

Pour enquêter sur les échecs Kerberos à l'aide de Silverfort:

1. Ouvrir les journaux d'authentification

2. Appliquer les filtres : Résultat IdP : Refuser, Protocole : Kerberos

3. Analyser les résultats

Étape 2 : Évaluer le risque – NTLMv1 vs NTLMv2

Toutes les utilisations de NTLM ne présentent pas le même niveau de risque. Un élément essentiel de votre plan d'élimination consiste à différencier NTLMv1 et NTLMv2. 

NTLMv1

NTLMv1 utilise DES pour son calcul de défi-réponse, un système bien trop faible par rapport aux normes actuelles. Les attaquants peuvent utiliser des tables arc-en-ciel ou des techniques de force brute modernes basées sur GPU pour déchiffrer les réponses NTLMv1 en quelques secondes. C'est pourquoi NTLMv1 doit être immédiatement bloqué dans tous les environnements. Continuer à l'autoriser expose les identifiants des utilisateurs à des risques inutiles. 

NTLMv2

NTLMv2 améliore la sécurité grâce à l'introduction de HMAC-MD5 et à l'ajout d'informations supplémentaires dans l'échange d'authentification. L'une des principales améliorations réside dans l'utilisation de paires attribut-valeur (AV_PAIRS), qui peuvent contenir des données telles que l'horodatage du client, le nom du serveur cible et les informations de la cible. Ces champs contribuent à la protection contre les attaques par rejeu et relais, car la réponse est liée à un serveur et à un contexte de session spécifiques. 

Cependant, la protection n'est pas complète. Si des attaquants parviennent à manipuler ou à supprimer les AV_PAIRS (par exemple, dans des configurations n'appliquant pas la validation de cible), des attaques par relais restent possibles. En pratique, NTLMv2 reste vulnérable aux attaques par transmission de hachage et au relais NTLM dans les scénarios où la signature et la liaison de canaux ne sont pas appliquées. 

Lors de l'élaboration de votre plan d'élimination de NTLM, il est important de prioriser les risques. NTLMv1 doit être considéré comme un risque immédiat et bloqué sans délai, car son utilisation crée une faille directe et facilement exploitable. surface d'attaqueBien que plus robuste, NTLMv2 ne doit être considéré que comme une solution temporaire. Il offre une meilleure protection que NTLMv1, mais expose néanmoins votre environnement aux attaques par relais et par hachage. Concrètement, cela implique d'éliminer d'abord NTLMv1, puis de se concentrer sur la réduction et l'élimination progressive de NTLMv2 jusqu'à sa suppression complète. 

Étape 3 : Bloquez NTLMv1 avec la stratégie de groupe et connaissez ses limites

Le blocage de NTLMv1 via la stratégie de groupe est une étape essentielle de tout plan d'élimination. La stratégie LMCompatibilityLevel (ou son équivalent dans la stratégie de groupe) permet de configurer les contrôleurs de domaine pour refuser les authentifications NTLMv1 et n'accepter que NTLMv2. Il s'agit de la configuration de base recommandée pour chaque domaine. Active Directory sûr et sécurisé. 

Comment activer la stratégie de groupe : 

1. Ouvrez Console de gestion de stratégie de groupe (GPMC). 

2. Accédez à : Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Options de sécurité 

3. Localisez le paramètre : Sécurité réseau : niveau d'authentification LAN Manager 

4. Définissez la valeur sur : Envoyer uniquement la réponse NTLMv2. Refuser LM et NTLM. 

Cela garantit que les systèmes Windows sont invités à générer uniquement des réponses NTLMv2 et que les contrôleurs de domaine rejettent les authentifications NTLMv1. 

Cependant, il est important de comprendre que ce contrôle seul ne vous protège pas totalement. Dans certains cas, des applications mal configurées peuvent forcer l'authentification NTLMv1 malgré le paramétrage de la stratégie de groupe. Cela crée un risque de fausse confiance : les administrateurs croient que NTLMv1 est bloqué alors qu'en réalité, il reste actif dans l'environnement. 

Pour une explication technique détaillée du fonctionnement d'un tel contournement et des raisons pour lesquelles il se produit, consultez mon article de blog : Contournement NTLMv1 dans Active Directory – Plongée technique approfondie. 

Ma recommandation actuelle est de surveiller et d’éliminer NTLMv1 et, si possible, de créer une politique basée sur les risques pour toutes les authentifications NTLMv1 à l’aide de Silverfort. 

Étape 4 : Vérifiez si les applications prennent en charge d’autres méthodes d’authentification

Une raison fréquente pour laquelle NTLM persiste dans certains environnements est l'hypothèse selon laquelle certaines applications ne fonctionnent qu'avec NTLM. Dans bien des cas, c'est faux. Les applications peuvent revenir à NTLM en raison d'une mauvaise configuration, de prérequis manquants ou simplement parce que les administrateurs n'ont pas activé de protocoles plus puissants. 

Avant de remplacer ou de retirer une application, vérifiez si elle prend déjà en charge une méthode d’authentification plus sécurisée : 

• Kerberos La plupart des applications Windows modernes sont compatibles avec l'authentification Kerberos lorsque les noms principaux de service (SPN) sont correctement configurés. De nombreuses dépendances NTLM peuvent être résolues en corrigeant les SPN ou en s'assurant que les clients se connectent via des noms d'hôte DNS plutôt que des adresses IP. 

• SAML, OpenID Connect (OIDC) ou OAuth – Les applications Web et les services cloud prennent souvent en charge ces normes d’authentification modernes, soit de manière native, soit via une intégration avec des fournisseurs d’identité (IdP). 

• Authentification par certificat – Certaines applications d’entreprise permettent une connexion par carte à puce ou par certificat, supprimant ainsi entièrement le besoin de NTLM. 

Lors de l’évaluation des candidatures : 

• Vérifier les versions ultérieures – Les versions plus récentes peuvent avoir abandonné les dépendances NTLM ou ajouté la prise en charge des protocoles d’identité modernes. 

• Enquêter sur la documentation – De nombreux fournisseurs documentent la prise en charge de Kerberos ou des identités fédérées, mais cette prise en charge reste souvent inutilisée. 

• Examiner les configurations d'identité – Assurez-vous que vos applications sont intégrées à votre fournisseur d’identité central dans la mesure du possible. 

Un bon exemple est Microsoft SQL Server accessible via le pilote officiel mssql-jdbc. À première vue, de nombreux déploiements semblent s'appuyer sur l'authentification NTLM. Cependant, en réalité, le pilote prend entièrement en charge cette authentification. Authentification Kerberos, à condition que les noms principaux de service (SPN) soient correctement configurés et que le client se connecte via un nom d'hôte DNS plutôt qu'une adresse IP. De plus, la documentation Microsoft explique comment configurer explicitement le pilote pour Kerberos, évitant ainsi le recours à NTLM. Dans ce cas, NTLM semble inévitable, mais en consultant la documentation et en ajustant les configurations d'identité, les administrateurs peuvent migrer l'application vers Kerberos et réduire l'utilisation de NTLM. 

Par ailleurs, envisagez d'ajouter l'authentification multifacteur (authentification multi-facteur) dans la mesure du possible. Même si NTLM ou Kerberos restent utilisés, l'authentification multifacteur réduit considérablement le risque de vol d'informations d'identification et l'utilisation abusive. Silverfort étend la protection MFA aux protocoles d'authentification tels que NTLM et Kerberos, offrant une couche de défense supplémentaire pour les systèmes hérités et modernes. 

Étape 5 : Prévoyez de fermer les applications basées sur NTLM

Une fois que vous avez identifié l'utilisation de NTLM, bloqué NTLMv1 et activé des alternatives plus puissantes lorsque cela est possible, l'étape finale consiste à planifier l'arrêt total des applications basées sur NTLMC’est la seule façon d’éliminer complètement les risques introduits par NTLM. 

Ce plan devrait inclure : 

Ameliorations – Migrez vers des versions plus récentes des applications prenant en charge Kerberos ou les normes d'authentification modernes. De nombreux fournisseurs ont abandonné les dépendances NTLM dans les versions récentes. 

Remplaçants – Lorsque les mises à niveau ne sont pas possibles, évaluez les options de remplacement qui correspondent à votre stratégie d’identité. 

Mise hors service – Établissez un calendrier clair pour la suppression des applications qui dépendent uniquement de NTLM. 

De plus, rappelez-vous que les clients jouent un rôle clé dans l'élimination du NTLM. Étant donné que le client est responsable du calcul NTLM, vous devez continuellement surveiller les clients revenant à NTLM et identifier les causes. Les causes courantes incluent : 

Utilisation de l'IP au lieu des noms d'hôtes – Lorsqu’un client se connecte avec une adresse IP plutôt qu’avec un nom d’hôte NetBIOS ou DNS, Kerberos ne peut pas être utilisé, ce qui force le retour à NTLM. 

Utilisation incorrecte de Kerberos dans les applications – Certaines applications n'implémentent pas Kerberos correctement et utilisent NTLM par défaut. Un bon exemple d'utilisation inappropriée est Vulnérabilités d'usurpation d'identité KDC identifiées par Silverfort dans plusieurs produits tels que IBM QRadar (CVE-2019-4545),  Cisco ASA et PAN-OS de Palo Alto Networks , où une gestion incorrecte de Kerberos a permis aux attaquants de contourner Kerberos et d'obtenir un accès élevé (lire la suite ici). 

Pour une aide-mémoire rapide de ces étapes que vous pouvez partager avec votre équipe, cliquez ici.

Il est essentiel de détecter et de résoudre ces problèmes pour empêcher NTLM de réapparaître silencieusement après que vous pensiez qu’il a été éliminé. 

La prochaine Fin de vie de Windows 10 et Microsoft annonce de l'abandon de NTLM Créez l'opportunité d'aligner ce plan de fermeture sur des projets plus vastes de modernisation informatique. Intégrez la suppression de NTLM à la modernisation de votre infrastructure. Ainsi, lorsque Windows 10 sera abandonné, votre environnement ne dépendra plus de NTLM.

Pour préparer votre équipe à ces changements cruciaux, Découvrez notre webinaire à la demande J'y explique comment mettre en évidence l'authentification NTLM et élaborer des politiques évolutives pour vous aider à l'éliminer.