NTLM et Kerberos expliqués en images — Pourquoi l'authentification « retombe »-t-elle sur NTLM ?

Même dans des réseaux d’entreprise dont on dit « chez nous c’est un environnement Kerberos », les journaux d’audit font toujours ressortir du NTLM. Et ce qui en ressort, ce sont le plus souvent des applications censées être compatibles avec Kerberos.

Pourquoi cela se produit-il ? La réponse saute aux yeux dès qu’on met côte à côte « ce que les deux protocoles cherchent à prouver ». Cet article détaille en images le fonctionnement de NTLM et de Kerberos afin de préciser, avec l’appui de la documentation officielle, dans quelles conditions l’authentification retombe sur NTLM, et pourquoi Microsoft cherche à abandonner NTLM.

La procédure de recensement de votre propre environnement (configuration des stratégies d’audit, suivi des événements, ordre des corrections) est détaillée dans l’article jumeau « La fin de NTLM va-t-elle bloquer vos applications métier ? ».

1. Conclusion, d’abord

• NTLM ne prouve qu’une seule chose : « détenir le hachage du mot de passe ». Les informations d’identification sont un hachage à sens unique du nom de domaine, du nom d’utilisateur et du mot de passe,¹ et dans le NTLMv2 utilisé par les Windows actuels, une clé dérivée de ce hachage sert à calculer et renvoyer un HMAC sur « le défi du serveur + l’horodatage + le défi côté client + les informations de cible » (section 2.2).²
• Kerberos prouve « qui, envers quel service ». Il délivre un ticket en utilisant comme clé le nom de service (SPN) de la destination, si bien qu’un ticket destiné à une autre destination ne peut pas être utilisé.³
• Les différences décisives sont au nombre de trois : la présence ou non d’une authentification mutuelle, le fait que le serveur interroge ou non le contrôleur de domaine (pour l’authentification par compte de domaine), et la possibilité ou non de déléguer. Microsoft l’indique clairement dans chaque cas (chapitre 5).⁴
• La cause première du repli sur NTLM est un « nom ». Kerberos ne peut rien commencer s’il ne peut pas dériver le SPN à partir du nom de la destination. Une adresse IP en dur, un SPN non enregistré, un groupe de travail, ou un chemin sans accès au DC sont les quatre facteurs principaux (chapitre 6).⁵⁶
• « Kerberos échoue » et « ça retombe sur NTLM » sont deux phénomènes différents. Le premier se produit lorsque Kerberos a été choisi mais rencontre une erreur (décalage d’horloge, par exemple) : l’authentification elle-même s’arrête. Le second se produit lorsque Kerberos n’a jamais pu démarrer et bascule silencieusement vers NTLM : l’activité continue de fonctionner. Commencez le diagnostic d’un incident par cette distinction (section 6.5).⁷
• L’attaque de relais fonctionne parce que NTLM ne comporte aucun mécanisme liant « à qui l’on s’authentifie ». Pass-the-Hash fonctionne parce que ce qui est nécessaire à l’authentification est le hachage lui-même (chapitre 7).⁸¹
• NTLMv1 est déjà supprimé. Cela concerne Windows 11 version 24H2 et Windows Server 2025. NTLMv2 est déprécié, mais fonctionne encore (chapitre 8).⁹
• Ce que les applications doivent écrire, c’est Negotiate. Negotiate choisit entre Kerberos et NTLM, et sélectionne Kerberos sauf si l’un des systèmes impliqués dans l’authentification ne peut pas l’utiliser.¹

2. Que fait NTLM ?

NTLM (Windows Challenge/Response) est, comme son nom l’indique, un protocole d’authentification par défi/réponse. Pour résumer l’explication de Microsoft : les informations d’identification se composent d’un hachage à sens unique du nom de domaine, du nom d’utilisateur et du mot de passe, obtenu lors de la connexion interactive, et pour authentifier sans faire transiter le mot de passe sur le réseau, la partie demandant l’authentification effectue un calcul prouvant qu’elle « a accès aux informations d’identification NTLM conservées en lieu sûr ».¹

Ce qui compte ici, c’est que le matériau de l’authentification n’est pas le mot de passe lui-même, mais son hachage. C’est précisément ce point qui rend possible Pass-the-Hash, que nous verrons plus loin.

2.1. Avec un compte de domaine, trois acteurs entrent en jeu

Lorsqu’un utilisateur déjà connecté accède, avec un compte de domaine, à une ressource sur un serveur (authentification non interactive), trois acteurs sont impliqués : le client, le serveur et le contrôleur de domaine. La particularité ici est que le serveur lui-même n’effectue pas le calcul d’authentification, mais le fait faire par le contrôleur de domaine.¹

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Serveur
    participant DC as Contrôleur de domaine

    Note over C: Lors de la connexion, calcule<br/>le hachage du mot de passe et jette le mot de passe lui-même
    C->>S: Nom d'utilisateur (en clair)
    S->>C: Nombre aléatoire de 8 octets (défi)
    Note over C: Chiffre le défi<br/>avec le hachage du mot de passe
    C->>S: Réponse
    S->>DC: Nom d'utilisateur / Défi / Réponse
    Note over DC: Extrait le hachage du SAM<br/>et refait le même calcul
    DC-->>S: Authentification réussie si identique
    S-->>C: Accès autorisé

Figure 1 : Authentification non interactive de NTLM (cas d’un compte de domaine)

Voici la procédure conceptuelle présentée par Microsoft (le calcul réel diffère avec NTLMv2 comme on le verra plus loin, mais les acteurs et la répartition des rôles restent ceux de ce schéma).¹

1. (Authentification interactive uniquement) L’utilisateur saisit le nom de domaine, le nom d’utilisateur et le mot de passe. Le client calcule le hachage cryptographique du mot de passe et jette le mot de passe réel.
2. Le client envoie le nom d’utilisateur en clair au serveur.
3. Le serveur génère un nombre aléatoire de 8 octets (défi, nonce) et l’envoie au client.
4. Le client chiffre ce défi avec le hachage du mot de passe de l’utilisateur et renvoie le résultat (réponse).
5. Le serveur envoie au contrôleur de domaine les trois éléments : nom d’utilisateur, défi envoyé au client, réponse reçue.
6. Le contrôleur de domaine extrait, à partir du nom d’utilisateur, le hachage du mot de passe dans la base SAM, et chiffre le défi avec.
7. Il compare son propre résultat calculé à la réponse du client ; s’ils sont identiques, l’authentification réussit.

2.2. Le calcul réel — NTLMv2 est un peu plus compliqué

Les 7 étapes ci-dessus constituent la forme de base présentée par Microsoft dans sa page de présentation. Le NTLMv2 réellement utilisé par les Windows actuels est un cran plus complexe que « chiffrer le défi avec le hachage du mot de passe ». La spécification ([MS-NLMP]) le définit ainsi.²

• La clé de réponse est NTOWFv2 = HMAC_MD5( MD4(UNICODE(mot de passe)), nom d'utilisateur en majuscules + nom de domaine )
• Le client construit temp en concaténant la version de réponse, l’horodatage, un défi de 8 octets généré côté client, et les informations de cible (paires AV)
• Le cœur de la réponse, NTProofStr = HMAC_MD5( clé de réponse, défi du serveur + temp )

En n’isolant que les matériaux et le flux de traitement, on obtient le schéma suivant.

flowchart TD
    PW["Mot de passe"] --> MD4["MD4(UNICODE(mot de passe))<br/>= hachage NT"]
    UD["Nom d'utilisateur en majuscules<br/>+ nom de domaine"] --> H1["HMAC_MD5"]
    MD4 -->|"utilisé comme clé"| H1
    H1 --> KEY["Clé de réponse NTOWFv2"]

    MAT["Version de réponse / horodatage /<br/>défi de 8 octets côté client /<br/>informations de cible (paires AV)"] --> TEMP["temp"]

    SC["Défi du serveur"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"utilisé comme clé"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

Figure 2 : Construction de la réponse NTLMv2 (mot de passe → hachage NT → clé de réponse → HMAC)

Autrement dit, on calcule en réalité un HMAC qui mélange non seulement le défi du serveur, mais aussi un nombre aléatoire côté client, un horodatage et des informations de destination. Le côté vérificateur reproduit le même calcul. Si le compte est dans Active Directory, la paire défi/réponse est envoyée au contrôleur de domaine pour vérification ; si le compte est local au serveur, le serveur calcule la valeur attendue en utilisant l’OWF qu’il conserve lui-même.²

Ce qui importe pour la suite de cet article, c’est que, malgré cette complexité, deux points restent inchangés.

1. Le matériau de la clé est encore aujourd’hui le hachage du mot de passe. Le point de départ de NTOWFv2 est MD4(UNICODE(mot de passe)), c’est-à-dire le hachage NT lui-même.² C’est pour cela que Pass-the-Hash fonctionne (section 7.2).
2. Le client ne vérifie pas si le serveur est authentique. L’explication de Microsoft selon laquelle NTLM n’a pas d’authentification mutuelle reste vraie avec NTLMv2.⁴

Le reste de cet article repose sur ces deux points.

2.3. Avec un compte local, tout se règle entre deux acteurs

Pour un compte local, la partie droite de ce schéma disparaît. Le serveur de ressources interroge le service d’authentification du contrôleur de domaine du domaine si le compte est un compte de domaine, mais consulte sa base de comptes locale si c’est un compte local.¹⁰ Autrement dit, pour une machine en groupe de travail, ou pour une connexion à un partage avec un compte local sur un serveur de fichiers, le contrôleur de domaine n’intervient pas : c’est un échange entre deux acteurs, où le serveur consulte son propre SAM et juge lui-même.

Cette différence se rattache directement au recensement des dépendances « Kerberos inutilisable parce que c’est un compte local », traité à la section 6.3. Même en consultant les journaux d’audit du contrôleur de domaine, le NTLM emprunté par ce chemin n’apparaît pas.

2.4. Trois conséquences de cette conception

En observant la figure 1, on peut directement lire les propriétés qui poseront problème par la suite.

• Le serveur ne prouve rien au client. L’échange est à sens unique : il n’existe nulle part de procédure par laquelle le serveur démontrerait « je suis authentique ».
• Le serveur ne peut juger que s’il détient lui-même le hachage. Chaque fois qu’un nouveau jeton d’accès est nécessaire, le serveur de ressources doit interroger le service d’authentification du contrôleur de domaine pour un compte de domaine, ou consulter sa base de comptes locale pour un compte local.¹⁰ C’est pour cela que l’authentification par compte de domaine dépend du contrôleur de domaine.
• La réponse est « valable pour ce défi uniquement », mais ne lie pas la destination. Comme le défi change à chaque fois, on ne peut pas réutiliser la même réponse. Mais comme aucun élément ne prouve « à quel serveur cette réponse est destinée », on ne peut pas s’apercevoir qu’elle a été détournée vers un autre serveur.

3. Pourquoi le serveur interroge-t-il le contrôleur de domaine ?

Dans l’authentification par compte de domaine, seule la base de comptes du contrôleur de domaine détient le hachage du mot de passe. Le serveur de ressources ne connaît pas le hachage de cet utilisateur et ne peut pas vérifier par lui-même. Il doit donc interroger le contrôleur de domaine à chaque authentification (authentification en relais, pass-through).¹⁰¹ (Pour un compte local, le serveur consulte son propre SAM et juge lui-même. La discussion qui suit sur la dépendance au contrôleur de domaine concerne le cas d’un compte de domaine.)

Cela a un coût, tant en matière de sécurité que d’exploitation. Microsoft explique que, dans l’authentification NTLM antérieure à Kerberos, un serveur d’application devait se connecter au contrôleur de domaine chaque fois qu’il authentifiait un client ou un service, alors qu’avec Kerberos, un ticket de session renouvelable remplace l’authentification en relais, et le serveur n’a pas besoin d’aller au contrôleur de domaine sauf si une vérification du PAC (certificat d’attributs de privilège) est nécessaire.⁴

Autrement dit, migrer vers Kerberos est à la fois une question de sécurité et, en même temps, une question de réduction de la dépendance au contrôleur de domaine.

4. Que fait Kerberos ?

L’approche de Kerberos diffère nettement de celle de NTLM. C’est un mécanisme où l’on ne refait pas la vérification d’identité à chaque authentification, mais où l’on ne se fait vérifier qu’une seule fois au départ pour recevoir un « ticket », que l’on présente ensuite.

Le KDC (centre de distribution de clés) fonctionne sur le contrôleur de domaine et utilise la base de données Active Directory Domain Services comme base de comptes de sécurité.⁴

sequenceDiagram
    autonumber
    participant C as Client
    participant KDC as KDC (contrôleur de domaine)
    participant S as Service (identifié par SPN)

    Note over C,KDC: Échange AS ── vérification d'identité et obtention du TGT
    C->>KDC: KRB_AS_REQ<br/>(nom d'utilisateur + horodatage chiffré avec la clé à long terme)
    Note over KDC: Si le déchiffrement avec la clé à long terme réussit, c'est bien lui
    KDC-->>C: KRB_AS_REP<br/>TGT (chiffré avec la clé de krbtgt) + clé de session

    Note over C,KDC: Échange TGS ── obtention du ticket de service
    C->>KDC: KRB_TGS_REQ<br/>(TGT + SPN de la destination + authentificateur)
    Note over KDC: Retrouve le compte de service à partir du SPN<br/>et chiffre le ticket avec sa clé à long terme
    KDC-->>C: KRB_TGS_REP<br/>Ticket de service + clé de session

    Note over C,S: Échange AP ── présentation au service
    C->>S: KRB_AP_REQ<br/>(ticket de service + authentificateur)
    Note over S: Déchiffrable avec sa propre clé à long terme<br/>= ticket qui lui est destiné
    S-->>C: KRB_AP_REP (si l'authentification mutuelle est demandée)

Figure 3 : Les trois échanges de Kerberos (AS / TGS / AP)

Légende — AS = Authentication Service (service d’authentification), TGS = Ticket Granting Service (service d’octroi de tickets), AP = Application. Dans les noms de messages, _REQ signifie « requête » et _REP signifie « réponse ». Par exemple, KRB_TGS_REQ signifie « requête au service d’octroi de tickets ».

4.1. Échange AS — la vérification d’identité, une seule fois

Le client envoie au KDC le nom d’utilisateur, le nom de domaine, et un horodatage chiffré avec sa propre clé à long terme (dérivée du mot de passe). C’est la pré-authentification (pre-authentication). Si le KDC parvient à déchiffrer avec cette clé à long terme et que l’horodatage est valide, il juge que « c’est bien lui ».³

Le KDC renvoie un TGT (ticket d’octroi de ticket). Le TGT est chiffré avec la propre clé à long terme du KDC (la clé du compte krbtgt), si bien que le client ne peut pas en lire le contenu. En même temps, la clé de session utilisée entre le client et le KDC est transmise, chiffrée avec la clé à long terme du client.³

Ce qu’il faut retenir ici, c’est que l’horodatage fait partie intégrante de l’authentification. C’est pour cela que Kerberos est strict sur la synchronisation de l’horloge : l’écart de temps toléré par défaut est de 5 minutes.⁷ Si l’on dépasse cette limite, la pré-authentification échoue, et l’authentification Kerberos elle-même échoue avec une erreur (la synchronisation de l’heure sous Windows est détaillée dans « Guide de la synchronisation de l’heure sous Windows (w32time) »). « Kerberos échoue » et « ça retombe sur NTLM » sont deux choses distinctes. Cette distinction est traitée à la section 6.5.

4.2. Échange TGS — déclarer « à quel service on se connecte »

C’est ici que la bifurcation décisive avec NTLM se produit. Le client communique au KDC le nom du service auquel il veut se connecter (SPN), et demande un ticket de service en joignant le TGT et un authentificateur.³

Le KDC recherche le compte de service correspondant à ce SPN, et chiffre le ticket de service avec la clé à long terme de ce compte avant de le renvoyer.³ D’où :

• Si le SPN ne peut pas être résolu, aucun ticket n’est délivré. Si le SPN n’est pas enregistré pour le compte de service, le KDC ne peut pas identifier le correspondant. Même en spécifiant la destination par une adresse IP, Kerberos n’est pas tenté par défaut (section 6.1).
• Le ticket est « exclusivement réservé à cette destination ». Comme il ne peut pas être déchiffré avec la clé à long terme d’un autre service, il ne peut pas être réutilisé pour une autre destination.

4.3. Échange AP — présentation au service et authentification mutuelle

Le client présente le ticket de service et un authentificateur au service. Le service déchiffre le ticket avec sa propre clé à long terme et en extrait la clé de session et les informations d’autorisation. Le fait même de pouvoir le déchiffrer constitue la preuve que « ce ticket lui est destiné ».³

Si le client a demandé une authentification mutuelle, le service renvoie l’horodatage reçu, chiffré avec la clé de session. En le vérifiant, le client peut confirmer que le correspondant est bien le service authentique.³ C’est une étape qui n’existe pas dans NTLM.

5. Les différences décisives

La ligne « Délégation » se ramifie encore davantage en pratique. Il existe plusieurs types de délégation — délégation sans contrainte, délégation contrainte (constrained delegation), délégation contrainte basée sur les ressources (RBCD) — et le choix entre elles devient un point de conception dans des architectures comme une application web frontend se connectant à un SQL Server backend avec les informations d’identification de l’utilisateur. Cet article n’entre pas dans ce détail, mais retenez ces termes comme prochaine piste de recherche si vous approfondissez la délégation Kerberos.

Les deux dernières lignes de ce tableau constituent directement « les raisons du repli sur NTLM ». C’est parce que la force de Kerberos (lier la destination, vérifier le correspondant) repose entièrement sur la capacité à résoudre correctement le nom.

6. Pourquoi l’authentification « retombe »-t-elle sur NTLM ?

Même si une application ne spécifie pas directement NTLM, NTLM peut être utilisé, parce que c’est le comportement de Negotiate. Selon Microsoft, Negotiate choisit entre Kerberos et NTLM, et sélectionne Kerberos sauf si l’un des systèmes impliqués dans l’authentification ne peut pas l’utiliser.¹

Autrement dit, « c’est devenu NTLM » signifie presque toujours, en d’autres termes, que « Kerberos n’a pas pu être utilisé. »

flowchart TD
    START["Authentification démarrée avec Negotiate"]
    Q1{"Compte de<br/>domaine ?"}
    Q2{"Un SPN peut-il être<br/>construit à partir du nom de la destination ?"}
    Q3{"Ce SPN est-il<br/>enregistré ?"}
    Q4{"Le KDC est-il<br/>joignable ?"}
    KRB["Authentification par Kerberos"]
    NTLM["Repli sur NTLM"]

    START --> Q1
    Q1 -->|"Non<br/>(groupe de travail / compte local)"| NTLM
    Q1 -->|Oui| Q2
    Q2 -->|"Non<br/>(adresse IP en dur)"| NTLM
    Q2 -->|Oui| Q3
    Q3 -->|"Non<br/>(SPN non enregistré / accès sous un alias)"| NTLM
    Q3 -->|Oui| Q4
    Q4 -->|"Non<br/>(site distant / VPN / pare-feu)"| NTLM
    Q4 -->|Oui| KRB

Figure 4 : L’arbre de décision par lequel Negotiate retombe sur NTLM

Voici d’abord les quatre facteurs principaux, présentés en trois colonnes : condition, raison, correction. Les détails sont traités à partir de la section 6.1.

6.1. Connexion par adresse IP

C’est la cause la plus fréquente. Microsoft précise clairement que par défaut, lorsque le nom d’hôte est une adresse IP, Windows ne tente pas d’authentification Kerberos pour cet hôte et se replie sur un autre protocole d’authentification valide comme NTLM.¹¹ Le guide d’audit indique lui aussi que si le « serveur cible » de l’événement 8001 n’est ni au format NetBIOS ni au format FQDN, Kerberos n’est pas utilisé.⁵

Et la raison pour laquelle cela se produit est également citée : des applications utilisant une adresse IP plutôt qu’un nom DNS à cause d’une erreur de configuration ou de la documentation d’un fournisseur.⁵ En pratique, on rencontre aussi très souvent des cas où un paramètre a été remplacé par une IP « parce que la résolution de nom était instable », et n’a jamais été rétabli depuis.

Cependant, c’est un comportement par défaut, pas une contrainte absolue. À partir de Windows 10 version 1507 et Windows Server 2016, il existe un mécanisme permettant d’utiliser une adresse IP comme nom d’hôte dans un SPN. En mettant à 1 la valeur de registre côté client TryIPSPN, puis en enregistrant manuellement le SPN de l’adresse IP sous la forme Setspn -s <classe de service>/<adresse IP> <compte>, Kerberos peut fonctionner même vers une adresse IP. Ce qu’il faut enregistrer, c’est la classe de service réellement demandée par le client : pour un service mappé sur HOST comme un dossier partagé, host/192.168.1.1 suffit, mais pour le Web il faut HTTP/192.168.1.1, et pour SQL Server un SPN distinct incluant le port, comme MSSQLSvc/192.168.1.1:1433. Enregistrer seulement host/ ne fera pas fonctionner Kerberos si cela ne correspond pas au SPN demandé. Microsoft positionne cette fonctionnalité précisément comme un moyen de réduire l’impact de la désactivation de NTLM.¹¹

Cela dit, ce n’est pas le premier choix. Microsoft lui-même indique qu’une adresse IP étant temporaire — pouvant entraîner des conflits ou des échecs d’authentification liés à l’expiration et au renouvellement d’un bail — elle n’est normalement pas utilisée à la place d’un nom d’hôte, et que l’enregistrement d’un SPN basé sur une IP est une opération manuelle à réserver aux cas où il est impossible de passer à un nom d’hôte basé sur le DNS.¹¹ Pour une adresse IP en dur trouvée lors d’un audit, envisagez d’abord de la remplacer par un FQDN. TryIPSPN est le dernier recours pour les correspondants où c’est vraiment impossible.

6.2. Le SPN n’est pas enregistré

C’est la deuxième cause la plus fréquente. Microsoft cite, parmi les types d’applications qui utilisent NTLM malgré leur compatibilité avec Kerberos, les applications dont le SPN n’est pas correctement configuré.⁵

Comme on l’a vu dans l’échange TGS de la figure 3, le KDC retrouve le compte de service à partir du SPN pour chiffrer le ticket. Sans SPN, le KDC ne peut pas identifier « la clé de ce service ». Le même phénomène se produit aussi lorsqu’on accède via un alias DNS (CNAME) ou un nom d’hôte personnalisé sans que le SPN de ce nom soit enregistré. L’application fonctionne correctement, mais seul le nom n’est pas inscrit au registre.

6.3. En dehors d’Active Directory, tout simplement

Un poste en configuration groupe de travail, ou un accès à un partage avec un compte local, ne sont pas sur le terrain de Kerberos. Microsoft indique également que NTLM est utilisé, et doit l’être, pour l’authentification Windows sur les systèmes configurés comme membres d’un groupe de travail et pour l’authentification de connexion locale en dehors des contrôleurs de domaine.¹⁰

C’est là la raison pour laquelle on ne peut pas « simplement interdire » NTLM. Le KDC local prévu en phase 2 est justement la fonctionnalité destinée à combler ce vide.⁶ Mais gardez à l’esprit que ce vide n’est comblé qu’entre Windows compatibles entre eux. Une authentification par compte local face à un Windows ancien, ou à un appareil d’un autre fabricant comme un NAS ou un copieur multifonction, ne deviendra pas automatiquement du Kerberos même une fois le KDC local disponible. Ce tri est traité aux chapitres 5 et 6 de l’article pratique.

6.4. Le KDC est injoignable

Un repli se produit aussi en cas de problème de chemin réseau, comme un contrôleur de domaine injoignable depuis un site distant ou via VPN, ou des ports nécessaires à Kerberos bloqués par un pare-feu.⁶ Sans pouvoir dialoguer avec le KDC, il n’y a aucun moyen d’obtenir un ticket, donc Negotiate choisit l’option restante : NTLM.

6.5. Ne pas confondre « l’échec de Kerberos » et « le repli sur NTLM »

Terminons par la distinction entre deux choses qui prêtent à confusion mais sont différentes. Les sections 6.1 à 6.4 ci-dessus décrivent toutes des cas où « Kerberos n’a pas pu démarrer. » Comme il n’a pas pu démarrer, Negotiate choisit NTLM.

À l’inverse, le cas où Kerberos a été choisi puis a échoué est différent. L’exemple typique est le décalage d’horloge. Si le SPN peut être résolu et que le KDC est joignable, Negotiate choisit d’abord Kerberos. Si ensuite l’écart de temps dépasse la tolérance (5 minutes par défaut), la pré-authentification échoue et cela se solde par une erreur Kerberos.⁷ Ce n’est pas parce que le protocole choisi échoue que Negotiate bascule automatiquement vers NTLM pour recommencer (sauf si l’application retente explicitement avec une autre méthode).

La conséquence pratique est simple : un incident de décalage d’horloge ne se retrouve pas en cherchant l’événement 8001. Les symptômes diffèrent aussi.

Distinguez d’abord « est-ce un repli sur NTLM, ou Kerberos est-il cassé » avant d’enquêter.

7. La différence vue du côté des attaques — relais et Pass-the-Hash

Dans la documentation de paramétrage des stratégies, Microsoft écrit clairement que l’authentification NTLM et NTLMv2 est vulnérable à diverses attaques malveillantes, notamment le relais SMB, l’attaque de l’intercepteur et les attaques par force brute.⁸ La figure 1 permet d’expliquer pourquoi.

7.1. L’attaque de relais — conséquence de l’absence de liaison à la destination

sequenceDiagram
    autonumber
    participant V as PC de la victime
    participant A as Serveur de l'attaquant
    participant T as Serveur authentique

    Note over V,A: Attire vers le serveur de l'attaquant
    V->>A: Démarre l'authentification (nom d'utilisateur)
    A->>T: Démarre l'authentification avec le même utilisateur
    T-->>A: Défi
    A-->>V: Transfère ce défi tel quel
    Note over V: Ne peut pas distinguer si cela vient<br/>bien du vrai serveur
    V->>A: Réponse (calculée avec la clé issue du hachage)
    A->>T: Transfère cette réponse telle quelle
    Note over T: Si ni la signature ni le channel binding<br/>ne sont exigés
    T-->>A: Authentification réussie → connexion établie en tant que la victime

Figure 5 : Réalisation d’un relais NTLM (correspondant sans signature ni liaison de canal)

L’attaquant n’a besoin de connaître ni le mot de passe ni le hachage. Il lui suffit de faire transiter le défi et la réponse d’un côté à l’autre. Cela fonctionne parce que, côté client, il n’existe aucun moyen de vérifier « si cette réponse parvient réellement au correspondant visé ».

Cependant, le relais ne fonctionne pas avec n’importe quel correspondant. Le fait que l’échange relayé devienne une session utilisable dépend des défenses de la destination.

• Cela ne fonctionne pas contre un correspondant qui exige la signature SMB. Microsoft indique clairement que la signature apposée sur chaque message SMB, qui comprend le hachage du message entier, vérifie l’identité de l’émetteur et du destinataire, ce qui empêche l’attaque de relais.¹² Notez que les contrôleurs de domaine exigent par défaut la signature SMB de la part de leurs correspondants.¹²
• Cela ne fonctionne pas non plus contre un service qui impose Extended Protection for Authentication (liaison de canal). Comme cela lie l’authentification au canal TLS sous-jacent, une authentification relayée vers un autre canal ne passe plus.

Autrement dit, ce que décrit la figure 5 est le chemin qui fonctionne à condition que le correspondant accepte NTLM sans exiger ni signature ni liaison de canal. À l’inverse, cela signifie aussi qu’il existe une mesure immédiatement actionnable en pratique. Il vaut la peine de vérifier, en parallèle du recensement de NTLM, l’état d’exigence de la signature SMB.

Avec Kerberos, ce type de relais n’est de toute façon pas possible. Comme le ticket de service est chiffré avec la clé à long terme du service de destination, il ne peut pas être déchiffré s’il est présenté à un autre service.³ De plus, le client peut vérifier, grâce à l’authentification mutuelle, si le correspondant est authentique.⁴

La raison pour laquelle Microsoft a mis en place le blocage NTLM côté client SMB est exactement celle-ci. L’objectif expliqué est d’empêcher la technique consistant à faire envoyer une requête NTLM à un serveur malveillant.¹³ Notez que, parmi les recommandations autour de la signature SMB, Microsoft cite aussi l’utilisation de Kerberos plutôt que NTLMv2 afin que la clé de session parte d’une base solide, ainsi que le fait de ne pas se connecter à un partage par adresse IP ou par un enregistrement CNAME (car cela ferait utiliser NTLM plutôt que Kerberos).¹² C’est le même sujet que les sections 6.1 et 6.2.

7.2. Pass-the-Hash — l’équivalence entre le hachage et le mot de passe

flowchart LR
    P["Mot de passe"] -->|"hachage à sens unique"| H["Hachage du mot de passe"]
    H -->|"dérive la clé de réponse<br/>et calcule le HMAC"| R["Réponse"]
    R --> AUTH["Authentification réussie"]
    STEAL["Vol du hachage<br/>depuis le poste"] --> H
    NOTE["Le mot de passe en clair<br/>n'est pas nécessaire"] -.-> STEAL

Figure 6 : Ce qui est nécessaire pour l’authentification, c’est le hachage, pas le mot de passe en clair

Les informations d’identification NTLM sont un hachage à sens unique du mot de passe.¹ Dans NTLMv2, MD4(UNICODE(mot de passe)) sert de clé pour dériver la clé de réponse, avec laquelle un HMAC est ensuite calculé pour former la réponse.² Même si la forme du calcul change, le point de départ reste le hachage. Autrement dit, ce qui est nécessaire pour l’authentification, c’est le hachage, pas le mot de passe en clair.

Cette conséquence a un poids opérationnel très lourd. Rendre le mot de passe plus long et plus complexe ne ferme pas le chemin par lequel le hachage peut être volé. Microsoft cite également Pass-the-Hash, aux côtés de la force brute et du cassage de mot de passe, parmi les attaques contrées par le blocage NTLM sur SMB.¹³

Kerberos possède lui aussi une clé à long terme, mais ce qui circule dans l’authentification quotidienne, ce sont des tickets à durée de validité limitée et des clés de session.³ La portée de ce qui peut être volé n’est pas la même.

8. NTLMv1, NTLMv2 et la « suppression »

NTLM n’est pas un protocole unique : c’est un ensemble de protocoles d’authentification comprenant LAN Manager versions 1 et 2, et NTLM versions 1 et 2.¹⁰

La situation actuelle se répartit ainsi.

Autrement dit, ce n’est pas « c’est du NTLMv2, on peut laisser de côté pour l’instant ». Mais la priorité est claire : les appareils et hôtes qui ne parlent qu’en NTLMv1 sont la priorité absolue. Un hôte où NTLM V1 est enregistré lors de l’audit verra son authentification échouer s’il est mis à niveau tel quel vers un Windows récent. La méthode pour distinguer les versions (consulter le « Nom du package (NTLM uniquement) » du journal de sécurité) est détaillée à la section 4.4 de l’article pratique.⁵

Notez que les stratégies d’audit et de blocage restreignant NTLM ont le même effet sur NTLMv1 et NTLMv2.⁵ Le comportement ne change pas selon la version lorsqu’on applique une restriction.

9. Et ensuite ?

Microsoft indique trois orientations.

La première consiste à utiliser Negotiate côté application. C’est l’instruction contenue dans l’annonce de dépréciation elle-même : les appels à NTLM devraient être remplacés par des appels à Negotiate.⁹ Il est également indiqué clairement que les applications ne devraient pas accéder directement au package de sécurité NTLM.¹

La deuxième consiste à réduire les situations où NTLM devient nécessaire. IAKerb et le KDC local, prévus en phase 2 (seconde moitié de 2026), correspondent à cela.⁶ C’est une tentative de combler, côté protocole, les deux lacunes vues à la section 6.3 : « Kerberos inutilisable parce que c’est un compte local » et « Kerberos inutilisable parce que le contrôleur de domaine est injoignable ». Mais l’étendue de ce qui sera comblé a des limites. Ce qu’IAKerb résout, c’est la joignabilité du contrôleur de domaine, pas la compatibilité du correspondant. Le KDC local, lui non plus, n’agit qu’entre Windows compatibles entre eux. Face à un NAS ou un copieur multifonction d’un autre fabricant, attendre la phase 2 ne changera rien à la situation ; il faudra choisir soi-même entre le remplacement de l’appareil, la jonction au domaine, le passage à un autre protocole, ou la gestion d’une exception.

La troisième consiste à changer le comportement par défaut. En phase 3, il est prévu que l’authentification NTLM réseau soit désactivée par défaut dans la prochaine version majeure.⁶ Il est cependant précisé qu’il restera possible de la réactiver via une stratégie.

Cet ordre a un sens. Comme la séquence est « éliminer les raisons d’utiliser NTLM, puis changer le comportement par défaut », trier dès maintenant, parmi vos dépendances restantes à NTLM, celles dont on peut espérer la résolution en phase 2 (authentification par compte local entre Windows compatibles, joignabilité du DC) et celles qu’il faut corriger soi-même (adresse IP en dur, SPN non enregistré, et authentification par compte local face à un Windows ancien ou un appareil d’un autre fabricant) vous évite des travaux inutiles. Si vous classez ce dernier cas dans « en attente de la phase 2 », il se manifestera comme une panne le jour où la désactivation par défaut arrivera. La procédure concrète de ce tri est détaillée dans l’article pratique.

10. Conclusion

• NTLM est un protocole qui prouve, par un défi/réponse, « la détention du hachage du mot de passe ». Le jugement est délégué au contrôleur de domaine pour un compte de domaine, tandis que le serveur lui-même consulte son propre SAM pour un compte local.¹¹⁰
• Kerberos prouve « qui, envers quel service ». Le ticket de service étant chiffré avec la clé à long terme du service de destination, il ne peut pas être réutilisé pour une autre destination.³
• Les différences décisives sont la présence ou non d’une authentification mutuelle, l’interrogation ou non du DC à chaque authentification, et la possibilité ou non de déléguer.⁴
• Le repli sur NTLM survient presque toujours quand « Kerberos n’a pas pu démarrer ». Adresse IP en dur, SPN non enregistré, en dehors d’Active Directory, KDC injoignable : ce sont les quatre causes principales.⁵⁶¹¹
• À l’inverse, un problème comme le décalage d’horloge, où Kerberos est choisi puis échoue, se manifeste comme une erreur d’authentification, pas comme un repli sur NTLM. Chercher l’événement 8001 ne le révélera pas.⁷
• L’attaque de relais fonctionne parce que la réponse NTLM ne lie pas la destination. Pass-the-Hash fonctionne parce que ce qui est nécessaire à l’authentification est le hachage lui-même.⁸¹¹³
• NTLMv1 est déjà supprimé (Windows 11 24H2 / Windows Server 2025), et toutes les versions, y compris NTLMv2, sont dépréciées.⁹
• Ce que les applications doivent écrire, c’est Negotiate. Au-delà de cela, uniformiser le nom de la destination sur un FQDN et enregistrer les SPN constituent, en pratique, ce qui fait fonctionner Kerberos.¹⁵

Articles connexes

• La fin de NTLM va-t-elle bloquer vos applications métier ? — Comment collecter les journaux d’audit et dans quel ordre éliminer les dépendances
• Les pièges des lecteurs réseau et des chemins UNC — gérer un serveur de fichiers (dossier partagé) dans une application métier
• Guide de la synchronisation de l’heure sous Windows (w32time)
• Explorer les journaux d’événements avec Get-WinEvent en pratique — la vitesse du filtrage détermine le temps d’enquête
• Gérer les informations d’identification en toute sécurité avec PowerShell — bannir les mots de passe en clair des scripts
• Qu’est-ce que le TPM sous Windows ? — le « coffre-fort qui ne laisse jamais sortir la clé » et le démarrage mesuré, expliqués en images
• Les 10 principales menaces de sécurité de l’information 2026 — comment lire ce classement, et ce que les PME doivent vraiment traiter

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge la modification d’applications métier Windows liée à une révision de la méthode d’authentification, ainsi que l’investigation des causes d’incidents d’authentification autour de Kerberos et NTLM.

• Développement d’applications Windows
• Investigation de dysfonctionnements et analyse des causes
• Valorisation des actifs existants et accompagnement à la migration
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

NTLM et Kerberos, au fond, qu'est-ce qui les différencie ?

La plus grande différence porte sur « la possibilité de vérifier l'identité de l'autre partie ». Microsoft indique clairement qu'avec NTLM, ni le client ne peut vérifier l'identité du serveur, ni un serveur celle d'un autre serveur. NTLM a été conçu pour des environnements où l'on peut supposer que « le serveur est authentique », alors que Kerberos ne fait pas cette hypothèse. La deuxième différence porte sur la nécessité, ou non, pour le serveur d'interroger le contrôleur de domaine. Avec NTLM, dans le cas d'une authentification par compte de domaine, le serveur d'application se connecte au contrôleur de domaine chaque fois qu'il authentifie un client (pour un compte local au serveur, le serveur consulte lui-même sa propre base de comptes pour juger, sans que le contrôleur de domaine intervienne). Avec Kerberos, un ticket de session renouvelable remplace cette authentification en relais, si bien que le serveur ne va pas au contrôleur de domaine, sauf si une vérification du PAC est nécessaire. La troisième différence est que Kerberos prend en charge la délégation par un service (le mécanisme par lequel un service se connecte à un autre service pour le compte du client).

Pourquoi une application censée être compatible avec Kerberos finit-elle par utiliser NTLM ?

Kerberos est un mécanisme qui délivre des tickets en utilisant « le nom de la destination » comme clé, donc cela ne fonctionne pas si le nom ne peut pas être résolu. Le client présente au KDC le SPN (nom de principal de service) de la destination pour demander un ticket de service, mais par défaut Windows ne tente pas l'authentification Kerberos lorsque le nom d'hôte est une adresse IP, et le KDC ne peut pas délivrer de ticket si le SPN n'est pas enregistré pour le compte de service. Le guide d'audit de Microsoft indique lui aussi que si le « serveur cible » de l'événement 8001 n'est ni au format NetBIOS ni au format FQDN, Kerberos n'est pas utilisé (pour une adresse IP, il est exceptionnellement possible de faire fonctionner Kerberos en configurant TryIPSPN côté client et en enregistrant manuellement le SPN de l'adresse IP, mais ceci est considéré comme un dernier recours lorsqu'il est impossible de passer à un nom DNS). Par ailleurs, l'authentification depuis une machine en groupe de travail ou avec un compte local (en dehors d'Active Directory de toute façon), un site sans accès au contrôleur de domaine, ou l'authentification vers un correspondant sans relation d'approbation sont aussi des conditions où Kerberos ne peut pas fonctionner. Comme Negotiate choisit NTLM lorsque Kerberos n'est pas utilisable, l'authentification « retombe » sur NTLM dans ces cas.

Qu'est-ce que l'attaque de relais NTLM ? Pourquoi fonctionne-t-elle ?

C'est une attaque où l'attaquant attire la victime vers son propre serveur, puis relaie tel quel vers le vrai serveur l'échange d'authentification NTLM qui y arrive, pour usurper l'identité de la victime. Elle fonctionne parce que le défi/réponse de NTLM ne comporte aucun mécanisme liant « à qui l'on s'authentifie ». Le client se contente de calculer une réponse à partir du défi émis par le serveur et de la renvoyer, sans aucun moyen, côté client, de vérifier si cette réponse est destinée au vrai serveur ou relayée par un attaquant. Microsoft lui-même indique clairement, dans sa documentation de paramétrage des stratégies, que l'authentification NTLM et NTLMv2 est vulnérable à diverses attaques malveillantes, notamment le relais SMB, l'attaque de l'intercepteur et les attaques par force brute. Cependant, le relais ne fonctionne pas avec n'importe quel correspondant. Si la destination exige la signature SMB, la signature vérifie l'identité de l'émetteur et du destinataire, ce qui empêche le relais ; il en va de même pour les services imposant Extended Protection for Authentication (liaison de canal). Autrement dit, ce sont les correspondants sans signature ni liaison de canal, acceptant NTLM, qui sont visés. Avec Kerberos, le ticket de service étant chiffré avec la clé à long terme de ce service, un ticket destiné à un autre service ne peut pas être déchiffré même s'il est présenté ailleurs.

Pass-the-Hash signifie-t-il qu'on peut usurper une identité sans casser le mot de passe ?

Exactement. Les informations d'identification NTLM se composent d'un hachage à sens unique du nom de domaine, du nom d'utilisateur et du mot de passe. Dans le NTLMv2 utilisé par les Windows actuels, la clé de réponse est dérivée comme un HMAC utilisant comme clé le hachage MD4 du mot de passe (hachage NT), puis un HMAC est calculé avec cette clé sur un ensemble regroupant le défi du serveur, l'horodatage, le défi généré côté client et les informations de cible. Ce n'est donc pas un simple chiffrement du défi, mais le point de départ reste le hachage du mot de passe. Autrement dit, ce qui est nécessaire pour l'authentification est le hachage, pas le mot de passe en clair. Par conséquent, un attaquant capable d'extraire le hachage, par exemple depuis la mémoire d'un poste, peut s'authentifier en tant que cet utilisateur sans jamais avoir à casser le mot de passe. Rendre le mot de passe plus long et plus complexe ne ferme pas ce chemin. L'une des raisons pour lesquelles Microsoft a mis en place le blocage NTLM côté client SMB est justement de contrer les attaques Pass-the-Hash.

Si nous utilisons NTLMv2, sommes-nous en sécurité pour l'instant ?

NTLMv2 est plus robuste que NTLMv1, mais il n'échappe pas pour autant à la dépréciation. La liste des fonctionnalités dépréciées de Microsoft indique que toutes les versions de NTLM, y compris LANMAN, NTLMv1 et NTLMv2, sont exclues du développement actif de fonctionnalités et dépréciées. Le comportement des stratégies de restriction est identique : les stratégies d'audit et de blocage ont le même effet sur les deux versions. En revanche, NTLMv1 est traité différemment : il n'est plus au stade de la dépréciation mais est entré dans la phase de suppression, et il est déjà supprimé depuis Windows 11 version 24H2 et Windows Server 2025. Il ne s'agit donc pas de se dire « c'est du NTLMv2, on peut laisser tel quel pour l'instant », mais plutôt de retenir que « NTLMv1 a une échéance immédiate, et il faut avancer le recensement de NTLMv2 en vue de sa désactivation par défaut ».

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.