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

« On dit que NTLM va être supprimé, est-ce que chez nous ça va aller ? » — depuis que Microsoft a annoncé en juin 2024 la dépréciation de toutes les versions de NTLM, nous recevons cette question de plus en plus souvent. La réponse est : on peut savoir si ça va aller en vérifiant, et il est encore temps de vérifier maintenant.

La fin de NTLM n’est pas le genre de changement où « un correctif tombe un jour et toute l’entreprise s’arrête ». C’est un resserrement progressif à chaque nouvelle version de l’OS, et surtout, c’est seulement maintenant, pendant que NTLM fonctionne encore, que vous pouvez dresser en toute sécurité la liste des endroits où votre entreprise dépend de NTLM. Tout arrêter puis chercher ce qui casse est le pire ordre possible.

Cet article se concentre sur la procédure pratique pour construire cette liste et l’éliminer. Le fonctionnement du protocole lui-même (pourquoi NTLM est dangereux, pourquoi l’authentification « retombe » sur NTLM) fait l’objet de l’article jumeau « NTLM et Kerberos expliqués en images — Pourquoi l’authentification « retombe »-t-elle sur NTLM ? ».

1. Conclusion, d’abord

• NTLM a été déprécié en juin 2024. Cela concerne toutes les versions, y compris LANMAN, NTLMv1 et NTLMv2 : c’est une déclaration signifiant « plus de développement actif de fonctionnalités ». Il est précisé dans le même temps que « l’utilisation de NTLM continuera de fonctionner dans la prochaine version de Windows Server et dans la prochaine version annuelle de Windows ».¹
• Une partie a déjà été supprimée. NTLMv1 a été supprimé dans Windows 11 version 24H2 et Windows Server 2025.¹
• La fin de NTLM se déroule en 3 phases. La phase 1 concerne la visibilité et l’audit de l’utilisation, la phase 2 (seconde moitié de 2026) apporte des fonctionnalités (IAKerb, KDC local) pour éliminer les cas où l’on est obligé de dépendre de NTLM, et la phase 3 désactive par défaut l’authentification NTLM réseau dans la prochaine version majeure.²
• Il n’y a qu’une seule chose à faire maintenant. Faire tourner le mode audit pour dresser la liste de « quel poste, quelle application, vers quel serveur » utilise NTLM (chapitre 4).
• L’enquête sur les comptes de domaine commence par le contrôleur de domaine. En suivant l’ordre événement 8004 → 8003 du serveur membre → 8001 du client, on arrive finalement jusqu’au nom de l’application (section 4.2). Mais l’authentification par compte local ne passe pas par le contrôleur de domaine, donc l’événement 8004 n’apparaît pas. Il faut alors la repérer via le 8003 côté serveur et le 8001 côté client.³
• La cause principale, dans la grande majorité des cas, est un « nom ». Une adresse IP en dur et un SPN non enregistré sont les deux facteurs majeurs, et les deux se corrigent sans avoir à reconstruire l’application (chapitre 5).³²
• Il existe un moyen sûr de tester sur un seul poste. Sous Windows 11 24H2 / Windows Server 2025, NET USE \\serveur\partage /BLOCKNTLM permet de vérifier « est-ce que ça se connecte sans NTLM ? » sans modifier aucune stratégie (chapitre 7).⁴
• Pour vos applications maison, remplacez les endroits qui nomment NTLM par Negotiate. Microsoft lui-même écrit qu’il ne faut pas accéder directement au package de sécurité NTLM (chapitre 8).⁵

2. Que signifie « déprécié » ?

Commençons par clarifier les termes. Si l’on explique cela en interne en laissant ce point flou, « il paraît qu’on ne peut déjà plus l’utiliser » et « il paraît que ça ira encore pendant des années » circuleront en même temps et sèmeront la confusion.

Pour résumer, la fiche NTLM de la liste des fonctionnalités dépréciées de Microsoft dit trois choses.¹

1. 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.
2. L’utilisation de NTLM continuera de fonctionner dans la prochaine version de Windows Server et dans la prochaine version annuelle de Windows.
3. Les appels à NTLM devraient être remplacés par des appels à Negotiate. Negotiate tente une authentification par Kerberos et ne se replie sur NTLM que lorsque c’est nécessaire.

Et une mise à jour ajoute que NTLMv1 a été supprimé dans Windows 11 version 24H2 et Windows Server 2025.¹

Autrement dit, l’état actuel est « déprécié (deprecated) », pas « supprimé (removed) ». Sauf pour NTLMv1, qui est déjà allé au-delà de la dépréciation et est entré dans la phase de suppression. Si un ancien copieur multifonction ou un NAS ne sait s’authentifier qu’en NTLMv1, une mise à jour vers Windows 11 24H2 devient directement une panne. Ce n’est pas une question d’avenir, c’est quelque chose qui se produit déjà.

Un autre point à retenir : NTLM conserve des usages pour lesquels il n’existe pas d’alternative. Microsoft indique clairement que NTLM continue d’être utilisé, et doit l’être, pour l’authentification Windows sur des systèmes en groupe de travail et pour l’authentification de connexion locale en dehors des contrôleurs de domaine.⁶ Le KDC local prévu en phase 2 est justement la fonctionnalité destinée à combler cette lacune où « NTLM est nécessaire pour les comptes locaux ».²

2.1. État actuel des 3 phases

La feuille de route de la fin de NTLM comporte 3 phases. Comme il s’agit d’informations liées à une date, elles sont présentées ici avec une date de référence (le tableau ci-dessous reflète la situation à juillet 2026).

Ce que ce tableau doit faire ressortir, c’est que seule la phase 1 est actionnable de vos propres mains, dès maintenant. Le tableau de décision du chapitre 6 mentionne à plusieurs endroits que les fonctionnalités de la phase 2 « peuvent constituer une solution », mais cela suppose toujours de vérifier au préalable leur état de disponibilité. Les délais de livraison peuvent changer, donc revérifiez impérativement le contenu de ce tableau au moment où vous prenez votre décision en interne.

3. Pourquoi NTLM disparaît — en 3 minutes

Voici le strict minimum pour éclairer votre décision de migration. Pour une explication détaillée en images, voir l’article jumeau.

Dans la documentation de paramétrage des stratégies, Microsoft écrit clairement que l’authentification NTLM et NTLMv2 est vulnérable à divers types d’attaques malveillantes, notamment le relais SMB, l’attaque de l’intercepteur (man-in-the-middle) et les attaques par force brute.⁷ À la racine de cela se trouvent les propriétés suivantes, généralement énoncées en comparaison avec Kerberos.⁸

• Pas d’authentification mutuelle. 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 réseau où l’on peut supposer que « le serveur est authentique ». Kerberos ne fait pas cette hypothèse. Cette différence est ce qui rend possible une attaque de relais consistant à faire envoyer des informations d’identification à un faux serveur.
• Le serveur interroge le contrôleur de domaine à chaque fois (pour un compte de domaine). Avec NTLM, un serveur d’application doit se connecter au contrôleur de domaine chaque fois qu’il authentifie un client avec un compte de domaine (pour un compte local au serveur, le serveur consulte sa propre base de comptes pour juger).⁶ Avec Kerberos, un ticket de session renouvelable remplace cette authentification en relais (pass-through), et le serveur n’a pas besoin de contacter le contrôleur de domaine, sauf si une vérification du PAC (certificat d’attributs de privilège) est nécessaire.
• Le matériau d’authentification est le hachage du mot de passe lui-même. 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 ; le client chiffre le défi avec ce hachage pour renvoyer la réponse.⁵ C’est de là que découle le fait que voler le hachage suffit à usurper l’identité, sans même connaître le mot de passe en clair.

En pratique, « pas d’authentification mutuelle » signifie que le simple fait d’essayer de se connecter à un partage SMB peut suffire à livrer des informations d’identification à un faux serveur. La raison pour laquelle Microsoft a mis en place le blocage NTLM côté client SMB est expliquée de la même façon : « empêcher qu’un serveur malveillant fasse envoyer une requête NTLM ».⁴

4. Audit — dresser la liste des endroits où NTLM est utilisé

C’est le cœur du sujet. Le guide de Microsoft précise lui aussi qu’avant de mettre en œuvre des stratégies de restriction, il est nécessaire de découvrir et d’auditer l’état actuel du trafic d’authentification NTLM.⁹

4.1. Activer le mode audit

Il y a trois stratégies à configurer. Elles se trouvent toutes sous Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité, et aucun redémarrage n’est nécessaire. Que le paramètre soit enregistré localement ou déployé par stratégie de groupe, il devient effectif dès son application.⁷

Cela dit, « pas besoin de redémarrer » et « effectif immédiatement sur tous les postes » sont deux choses différentes. Si vous déployez via une GPO de domaine, enregistrer la GPO ne met à jour que la stratégie sur AD/SYSVOL ; chaque poste ne commence réellement l’audit qu’après la prochaine mise à jour en arrière-plan ou après un gpupdate /force. Comptez le début de la période d’audit non pas à partir de « la date d’enregistrement de la GPO », mais à partir de « la date où l’application s’est propagée aux postes cibles ». Se tromper sur ce point fausse les résultats du premier dépouillement, dont le nombre de postes couverts sera trop faible.

La troisième stratégie, « Trafic NTLM sortant vers des serveurs distants », a quatre valeurs possibles : Tout autoriser / Tout auditer / Tout refuser / Non défini, « Non défini » étant traité comme équivalent à « Tout autoriser ». La recommandation de Microsoft est claire : ne choisissez pas directement « Tout refuser » ; commencez par « Tout auditer », examinez le journal d’exploitation, identifiez quels serveurs reçoivent des demandes d’authentification, puis constituez une liste d’exceptions.⁷

Les enregistrements se trouvent dans Observateur d’événements > Journaux des applications et des services > Microsoft > Windows > NTLM (Microsoft-Windows-NTLM/Operational). Comme il n’existe pas de stratégie d’événements d’audit de sécurité correspondant à cet audit, il faut consulter ce canal plutôt que le journal de sécurité.⁷

Sur le terrain, la confusion la plus fréquente porte sur la correspondance entre « sur quelle machine appliquer quelle stratégie, et quel événement consulter ». En désignant les trois stratégies du tableau ci-dessus par ①②③, voici une liste de vérification.

Le journal est le même Microsoft-Windows-NTLM/Operational sur toutes les machines. ① n’a d’effet que sur les contrôleurs de domaine, et un poste sur lequel on a oublié d’activer ②③ ne devient pas « un poste qui n’utilise pas NTLM » mais « un poste qui n’enregistre rien ». Cette différence est la principale cause de biais dans le dépouillement.

Remarque : le mode audit se contente d’enregistrer, il ne bloque rien. En revanche, dans un environnement avec de nombreux postes, le volume de journaux augmente d’un coup. Si vous n’utilisez pas la collecte d’événements (WEF), revoyez d’abord la taille maximale et la durée de conservation des journaux avant d’activer l’audit. Le guide de Microsoft indique lui aussi que l’analyse peut prendre plusieurs mois selon la complexité de l’environnement.³

4.2. Le suivi se fait « du contrôleur de domaine vers l’aval »

Il existe un ordre déterminé pour interpréter les événements collectés. Le chemin de suivi indiqué par le guide de Microsoft est le suivant.³

flowchart TD
    DC["Contrôleur de domaine<br/>Événement 8004"]
    MS["Serveur membre<br/>Événement 8003"]
    CL["Client<br/>Événement 8001"]
    APP["Application responsable"]

    DC -->|"Nom du canal sécurisé =<br/>serveur à examiner"| MS
    MS -->|"Nom de la station de travail =<br/>client à examiner"| CL
    CL -->|"Nom du processus client"| APP
    MS -.->|"Si le PID est 4 (SYSTEM),<br/>c'est via SMB"| CL

Figure 1 : Ordre de suivi des événements d’audit NTLM

Voici les éléments à examiner pour chaque événement.³

Dans ce parcours, ce qui a le plus de valeur, ce sont le « serveur cible » et le « nom du processus client » de l’événement 8001. Le premier indique directement « pourquoi ce n’est pas devenu Kerberos », le second « qui est responsable ». Le guide de Microsoft explique également que ces informations permettent d’identifier qu’un utilisateur se connecte à l’adresse IP d’un serveur web sans utiliser le nom NetBIOS ou le FQDN qui aurait permis Kerberos.³

Notez aussi qu’il existe des cas où l’événement 8004 n’apparaît pas sur le contrôleur de domaine. C’est le cas lorsqu’une connexion à un serveur de fichiers se fait avec un compte utilisateur local, dont l’authentification ne passe pas par le contrôleur de domaine.³ Ne concluez jamais « les journaux du DC en montrent peu, donc tout va bien ».

4.3. Dépouiller avec PowerShell

Parcourir des milliers d’entrées dans l’interface graphique de l’Observateur d’événements n’est pas réaliste, on les regroupe donc avec Get-WinEvent. Commencez par vérifier combien d’événements de chaque type apparaissent sur cette machine.

# Regrouper les événements NTLM/Operational par ID (exécuter avec des privilèges administrateur)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

Une fois vérifié que des événements apparaissent, regroupez le 8001 côté client par « serveur de destination × processus appelant ». La structure des champs varie selon l’ID d’événement, il est donc plus sûr de commencer par ouvrir une seule entrée avec Format-List pour en vérifier la structure avant de fixer les index.

# Vérifier d'abord le contenu d'une seule entrée
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# Pour consulter les champs structurés
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

Une fois la structure connue, extrayez les valeurs via l’attribut Name du XML pour les dépouiller. Les noms d’attributs varient selon la version de l’OS, donc rechercher par nom est plus robuste qu’indexer par position.

# Dépouiller le 8001 des 7 derniers jours par « destination × processus appelant »
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # Ne retenir que les noms de champs réellement présents, par ordre de priorité
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Le dernier dépouillement renvoie deux colonnes : Count (nombre d’occurrences) et Name (concaténation par une virgule de « destination, processus appelant »). Autrement dit, la sortie a cette forme (les valeurs sont des exemples à titre d’illustration).

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

Ce qu’il faut regarder, c’est la première moitié de Name, c’est-à-dire la destination. Voici comment interpréter chaque ligne.

La valeur absolue du nombre d’occurrences n’a pas beaucoup de sens en soi. Regardez ces deux points : « les lignes visant une adresse IP arrivent-elles en tête ? » et « combien de lignes vont jusqu’à identifier le nom de l’exécutable ? » Le premier est une dépendance qui diminuera sûrement une fois corrigée, le second une dépendance à laquelle on peut affecter un responsable.

Comme les noms de champs varient selon la version de l’OS, le script range les candidats dans un tableau ordonné par priorité et ne retient que ceux qui existent réellement. Si vous utilisez ici une correspondance partielle comme -match 'Process', cela peut aussi capter un champ de PID comme ClientProcessId, et vous risquez de dépouiller par un PID qui change à chaque fois plutôt que par le nom de l’exécutable (l’ordre des clés d’une table de hachage n’étant pas garanti, on ne sait même pas de façon stable lequel des deux sera retenu). Si la colonne Process est entièrement vide, c’est le signe que les noms candidats ne correspondent pas au schéma réel, il faut alors ajouter au tableau les noms vérifiés à l’étape précédente.

Pour collecter depuis plusieurs postes, il est plus rapide de paralléliser avec PowerShell Remoting (voir « Introduction à PowerShell Remoting (WinRM) »). Le filtrage de Get-WinEvent prend un temps radicalement différent selon que l’on utilise -FilterHashtable ou non ; les points clés sont détaillés dans « Explorer les journaux d’événements avec Get-WinEvent en pratique ».

4.4. Regard depuis le journal de sécurité — NTLMv1 est-il encore utilisé ?

Indépendamment du journal NTLM/Operational, il existe aussi une méthode pour vérifier la version de NTLM à partir des événements de connexion du journal de sécurité. La procédure consiste à rechercher « Package d’authentification » dans le journal de sécurité et à examiner les « Informations d’authentification détaillées » de chaque événement.³

Informations d'authentification détaillées :
    Processus de connexion :          NtLmSsp
    Package d'authentification :      NTLM
    Service migré :                   -
    Nom du package (NTLM uniquement) : NTLM V1
    Longueur de clé :                 128

Ce « Nom du package (NTLM uniquement) » indique quel sous-protocole du groupe de protocoles NTLM a été utilisé.³ Un hôte affichant NTLM V1 est un candidat qui, une fois mis à niveau tel quel vers Windows 11 24H2 / Windows Server 2025, verra son authentification échouer, car NTLMv1 est supprimé dans ces versions.¹ Lorsque vous menez l’audit, accordez une priorité plus élevée à ce seul critère.

4.5. Quand le PID est toujours 4 (SYSTEM) et qu’on ne progresse plus

Dès qu’on commence l’audit, on se heurte presque toujours à cet obstacle. Pour les applications qui communiquent via un redirecteur, comme SMB (dossier partagé), c’est le redirecteur en mode noyau qui demande l’authentification, si bien que le PID conservé dans l’événement est toujours 4 (SYSTEM).³

Voici la démarche indiquée par le guide de Microsoft.³

1. Installer un outil de surveillance des processus sur le client qui envoie les informations d’identification NTLM (l’« ordinateur » de l’événement 8001).
2. Filtrer les chemins par le nom d’ordinateur et l’adresse IP du serveur en face, à la fois. Si une capture longue est nécessaire, la faire tourner en mode arrière-plan.
3. Recouper le résultat de la capture avec l’horodatage de l’événement 8003 côté serveur. L’utilisateur, le chemin et l’identifiant d’authentification correspondent entre eux, ce qui permet d’identifier l’application appelante.

L’outil en question est Process Monitor (ProcMon). La façon de poser les filtres et de lire les résultats est détaillée dans « Guide pratique de Process Monitor (ProcMon) ».

Une astuce pratique supplémentaire : il est nettement plus rapide de restreindre entièrement « quel poste » via les seuls journaux d’événements jusqu’à ce stade, puis de ne déployer ProcMon que sur ce seul poste. Déployer ProcMon sur tous les postes n’est pas réaliste.

5. Schémas typiques de repli sur NTLM

Une fois les emplacements identifiés par l’audit, l’étape suivante est de classer les causes. Le guide de Microsoft cite les quatre catégories suivantes d’applications qui, en théorie compatibles avec Kerberos, finissent par utiliser NTLM.³

• Applications qui permettent de choisir parmi diverses configurations de sécurité ou divers fournisseurs
• Applications dont le SPN (nom de principal de service) n’est pas correctement configuré
• Applications qui utilisent une adresse IP plutôt qu’un nom DNS à cause d’une erreur de configuration ou de la documentation d’un fournisseur
• Applications dont la base de code héritée conserve une partie spécifique à NTLM

Le blog de support Microsoft Japan cite comme causes typiques de recours à NTLM : l’accès au serveur par adresse IP, la restriction par pare-feu des ports nécessaires à Kerberos, le SPN non enregistré, l’authentification vers une relation d’approbation, et l’authentification en environnement de groupe de travail.²

En les organisant sous la forme rencontrée sur le terrain, on obtient le tableau suivant. Les deux colonnes de droite sont des critères pour établir les priorités. « Portée de l’impact » représente l’ampleur de la gêne en cas d’arrêt, « Facilité de correction » indique si cela peut être corrigé par la seule décision de l’entreprise. Une fois ces deux éléments connus, ils donnent directement l’ordre de traitement du plan.

L’ordre de traitement découle mécaniquement de ces deux colonnes.

1. Priorité absolue, indépendamment de la portée de l’impact : les appareils qui ne savent parler qu’en NTLMv1, et les hôtes où NTLM V1 est enregistré (section 4.4). C’est le seul cas où « l’échéance est déjà arrivée », il se place donc en dehors du calcul de priorité.¹
2. Vient ensuite Portée de l’impact = grande et Facilité de correction = élevée, c’est-à-dire les adresses IP en dur. Le volume est élevé et cela se corrige par la seule décision de l’entreprise. Concentrez-vous là-dessus le premier mois.
3. Puis les problèmes de SPN, à Facilité de correction = moyenne. À traiter en même temps que l’uniformisation des noms.
4. Pour les éléments à Facilité de correction = faible (dépendant d’un appareil, du chemin réseau, en attente de la phase 2), ce n’est pas que leur traitement est retardé, c’est simplement que leur délai est long : commencez dès maintenant, en parallèle des points 1 à 3, au moins la prise de contact avec le fournisseur et la budgétisation.

Les éléments classés « corrigeable immédiatement » et « se corrige par l’enregistrement d’un SPN » devraient représenter la majorité des résultats d’audit. Le simple fait de les éliminer réduit considérablement le nombre d’exceptions restantes.

6. Tableau de décision pour les corrections

7. Blocage NTLM sur SMB — le chemin le plus rapide pour une vérification sur le terrain

Les journaux d’audit indiquent que NTLM « est utilisé », mais pas ce qui se passerait « si on l’arrêtait ». C’est là qu’intervient utilement le blocage NTLM côté client SMB, ajouté dans Windows Server 2025 et Windows 11 version 24H2.⁴

Cette fonctionnalité empêche un client SMB d’utiliser l’authentification NTLM pour ses connexions sortantes vers un serveur distant. Microsoft indique que cela empêche la technique consistant à faire envoyer une requête NTLM à un serveur malveillant, et permet de contrer les attaques par force brute, par cassage de mot de passe et Pass-the-Hash, et positionne en outre le blocage NTLM comme nécessaire pour faire basculer le protocole d’authentification de l’organisation vers Kerberos. Il est également précisé qu’il est possible d’activer cette seule couche de protection sans désactiver complètement NTLM.⁴

Il y a deux prérequis.⁴

• Le client SMB doit être Windows Server 2025 ou ultérieur, ou Windows 11 version 24H2 ou ultérieure
• Le serveur SMB de destination doit pouvoir utiliser Kerberos (l’OS côté serveur SMB peut être n’importe lequel du moment qu’il prend en charge PKU2U ou Kerberos)

7.1. D’abord tester avec un seul poste et une seule connexion

Plutôt que de déployer directement une stratégie, on utilise le fait qu’il est possible de spécifier le blocage au niveau d’une connexion individuelle. C’est le chemin le plus rapide pour une vérification sur le terrain.

# Essayer de se connecter en interdisant NTLM uniquement pour cette connexion (si ça se connecte, ce partage n'a pas besoin de NTLM)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# On peut faire la même chose avec un mappage PowerShell
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

Si la connexion réussit, ce chemin fonctionne sans NTLM. Si elle échoue, c’est un point de dépendance à NTLM. Comme on peut vérifier connexion par connexion « est-ce que ça casserait en production », sans modifier aucune stratégie, c’est bien adapté pour recouper les résultats de l’audit.

Il y a trois endroits où vérifier le résultat. (1) Le succès ou l’échec de la connexion se lit dans le résultat de la commande elle-même : en cas de succès, un mappage est créé et apparaît dans la liste net use et dans Get-SmbConnection -ServerName <nom du serveur> ; en cas d’échec, cela se termine par une erreur et aucun mappage ne subsiste. (2) Pour savoir si c’est vraiment dû à NTLM, on juge en association avec l’étape 3 ci-dessous (connexion sans le drapeau) : si ça échoue même sans le drapeau, c’est un autre problème. (3) Pour confirmer avec quoi l’authentification s’est faite, utilisez la méthode décrite à la fin de cette section (klist et le journal de sécurité côté serveur). Ne concluez jamais à une dépendance à NTLM sur la seule base du texte du message d’erreur.

Cependant, cette vérification exige une procédure. L’exécuter sans y réfléchir conduit à des jugements erronés dans les deux sens.

$server = 'fileserver.corp.example.com'

# 1. Supprimer « absolument tous » les mappages vers ce serveur
#    S'il reste ne serait-ce qu'un seul autre partage, la session au niveau du serveur continue de vivre
net use | Select-String $server              # D'abord regarder ce qui est actuellement connecté
net use \\$server\share  /delete
net use \\$server\other  /delete             # Ainsi que tous les autres partages du même serveur

# 2. Vérifier que la session a vraiment disparu (ne pas passer à la suite tant que ce n'est pas vide)
Get-SmbConnection -ServerName $server

# 3. D'abord vérifier que la connexion réussit sans le drapeau (un échec ici indique un autre problème que NTLM)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # Remettre à vide ici aussi

# 4. Puis essayer avec le drapeau /BLOCKNTLM
net use \\$server\share /BLOCKNTLM

• Pourquoi les étapes 1 et 2 sont nécessaires : une session SMB est au niveau du serveur, pas au niveau du partage. S’il reste une session déjà authentifiée vers ce serveur, le redirecteur la réutilise sans refaire l’authentification. /BLOCKNTLM n’agit que sur l’authentification effectuée pour ce mappage précis ; il ne vérifie pas rétroactivement une session déjà établie (qui pourrait avoir été montée via NTLM). Autrement dit, il ne suffit pas de /delete uniquement le partage testé. Si un autre partage du même serveur reste connecté, la connexion réussira alors même qu’une dépendance à NTLM existe. Descendez jusqu’à ce que Get-SmbConnection ne renvoie plus rien. Au-delà de vos propres mappages, une application résidente ou une tâche de sauvegarde peut aussi détenir une session. Pour être sûr, le plus rapide est de tester depuis un poste qui ne s’est jamais connecté à ce serveur.
• Pourquoi l’étape 3 est nécessaire : une résolution de nom en échec, des informations d’identification incorrectes, ou un droit d’accès insuffisant au partage lui-même font aussi échouer une exécution avec /BLOCKNTLM. Si ça échoue même sans le drapeau, ce n’est pas une dépendance à NTLM mais un autre problème.

Notez que ce qu’on peut affirmer ici se limite à « NTLM n’était pas nécessaire », pas jusqu’à « l’authentification s’est faite par Kerberos ». Le prérequis de cette fonctionnalité est « un serveur SMB pouvant utiliser Kerberos », mais la destination peut aussi être un OS prenant en charge PKU2U.⁴ Il reste donc possible que la raison du succès soit PKU2U plutôt que Kerberos. Face à un serveur de fichiers déjà joint au domaine, cela ne pose généralement pas de problème, mais si vous voulez confirmer précisément avec quoi l’authentification s’est faite, exécutez klist sur le client après la connexion pour voir si un ticket cifs/ pour ce serveur a bien été obtenu, ou vérifiez le package d’authentification de l’événement de connexion dans le journal de sécurité côté serveur (section 4.4).

7.2. Activer par poste

Une fois la vérification faite, passez au blocage complet sur des postes pilotes.⁴

# Bloquer NTLM pour tout le client SMB (privilèges administrateur)
Set-SmbClientConfiguration -BlockNTLM $true

Avec une stratégie de groupe, activez « Bloquer NTLM (LM, NTLM, NTLMv2) » sous Configuration ordinateur > Modèles d'administration > Réseau > Station de travail Lanman.⁴

7.3. Pour les correspondants qui doivent absolument rester : la liste d’exceptions

Pour les correspondants qui ont absolument besoin de NTLM, comme un serveur SMB non joint au domaine, une exception est possible. Activez Station de travail Lanman > Bloquer la liste d'exceptions de serveurs NTLM dans la stratégie de groupe, et énumérez l’adresse IP, le nom NetBIOS ou le FQDN des correspondants autorisés.⁴

Comme il n’existe pas de cmdlet PowerShell pour créer la liste d’exceptions elle-même, il faut la configurer une première fois via l’éditeur de stratégie de groupe, mais une fois qu’elle existe, on peut y ajouter des entrées individuellement par une opération sur le registre.⁴

# Ajouter une entrée à la liste d'exceptions existante
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

Remarque : dans l’exemple fourni par la documentation Microsoft, la branche prévue pour le cas où la valeur n’existe pas encore se contente de définir @(""), ce qui jette purement et simplement les entrées qu’on voulait ajouter.⁴ Le comportement qui en résulte est qu’aucune exception n’entre lors de la première exécution, et qu’elles n’entrent finalement qu’à la deuxième exécution ; le code ci-dessus écrit donc directement les entrées à ajouter même dans le cas où la valeur n’existe pas encore. Cela dit, cette valeur de registre relève de toute façon d’une zone gérée par la stratégie de groupe. Gérez les exceptions permanentes du côté de la stratégie de groupe, et limitez cette opération à une réponse temporaire en cas d’urgence : la prochaine application de la stratégie l’écrasera.

Remarque : cette fonctionnalité est une fonctionnalité côté client SMB.⁴ Elle n’arrête pas NTLM sur des chemins autres que SMB (communication HTTP d’une application maison, connexion à SQL Server, WinRM, etc.). Ces cas-là doivent être éliminés individuellement selon la classification du chapitre 5.

8. NTLM du point de vue du développeur — utiliser Negotiate

Si votre entreprise développe des applications Windows, l’endroit à corriger est clair. Microsoft l’indique explicitement :⁵

Les applications ne devraient pas accéder directement au package de sécurité NTLM. Elles devraient utiliser à la place le package de sécurité Negotiate. Negotiate permet de tirer parti d’un protocole de sécurité plus avancé si les systèmes impliqués dans l’authentification le prennent en charge. Actuellement, le package de sécurité Negotiate choisit entre Kerberos et NTLM. Negotiate sélectionne Kerberos, sauf si l’un des systèmes impliqués dans l’authentification ne peut pas l’utiliser.

Autrement dit, le principe est de remplacer les endroits où « NTLM » est écrit par « Negotiate ». La liste des fonctionnalités dépréciées dit la même chose : les appels à NTLM devraient être remplacés par des appels à Negotiate.¹

8.1. Le cas fréquent en .NET : « nommer explicitement NTLM »

// Mauvais exemple : le type d'authentification nomme explicitement NTLM
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// Bon exemple : on ne change que le type d'authentification. Les informations d'identification sont transmises telles quelles
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

Ce qui change ici, c’est uniquement la chaîne du type d’authentification. Si vous remplacez credential par CredentialCache.DefaultNetworkCredentials, ce n’est pas seulement le protocole d’authentification qui change, c’est aussi l’identité qui s’authentifie. L’authentification se fera alors avec le compte exécutant le processus (compte de service ou utilisateur connecté) plutôt qu’avec le compte spécifié, ce qui peut cesser de fonctionner selon les droits configurés côté destination. Traitez le remplacement du protocole et la révision des informations d’identification comme deux changements distincts, à mener séparément.

À l’inverse, si vous voulez délibérément vous authentifier avec les informations d’identification de l’utilisateur connecté (authentification Windows intégrée), l’écriture peut être plus simple. C’est la façon d’écrire à utiliser quand on change intentionnellement « en tant que qui » on s’authentifie.

// Authentification Windows intégrée (s'authentifie avec l'utilisateur actuellement connecté)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

La gestion de HttpClient lui-même (ne pas l’envelopper dans un using, patrons de création, conception des délais d’expiration) est détaillée dans « N’enveloppez pas HttpClient dans un using ».

Si vous devez manipuler SSPI directement, System.Net.Security.NegotiateAuthentication, ajouté à partir de .NET 7, permet de gérer l’authentification via Negotiate depuis du code managé. Là aussi, le point clé est de ne pas spécifier NTLM comme nom de package.

8.2. Avant même le code : « comment la destination est écrite »

Même en corrigeant le code, si la destination reste une adresse IP, cela finira quand même par retomber sur NTLM. 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 valide comme NTLM.¹⁰ Concrètement, vérifiez les points suivants.

• Le nom de serveur écrit dans les fichiers de configuration (appsettings.json, App.config, fichiers ini)
• La spécification du serveur dans la chaîne de connexion SQL Server (Data Source)
• Les endroits où un chemin UNC est construit — présence d’adresses IP codées en dur
• Les valeurs par défaut de l’installeur ou des procédures de préparation de poste
• Les endroits où, lors d’une résolution d’incident passée, le nom a été remplacé par une IP « parce que la résolution de nom était instable », sans jamais être revenu en arrière

Le dernier point se rencontre vraiment très souvent. L’adresse IP en dur était, à l’époque, un remède d’urgence correct, mais c’est aujourd’hui une dette technique.

8.3. Si vous développez le côté service

Si vous voulez que votre service Windows maison ou votre application IIS accepte Kerberos, il faut enregistrer un SPN, pour le compte qui déchiffre le ticket, correspondant au nom que le client utilise pour y accéder. Comme Microsoft lui-même le cite en exemple représentatif, une application dont le SPN n’est pas enregistré retombera sur NTLM, même en se disant compatible Kerberos.³

Si l’on considère naïvement que le compte cible est « le compte qui exécute le service », on trébuche avec IIS. L’authentification Windows d’IIS a par défaut l’authentification en mode noyau activée, auquel cas ce n’est pas l’identité du pool d’applications mais le compte machine utilisé par HTTP.sys qui déchiffre le ticket Kerberos. Même si le pool d’applications s’exécute sous un compte de domaine dédié, enregistrer le SPN HTTP du site sur ce compte crée un décalage entre le titulaire du SPN et le compte qui déchiffre réellement, si bien que l’authentification échoue purement et simplement avec KRB_AP_ERR_MODIFIED, bien pire qu’un simple repli sur NTLM.

Le point clé est de « faire correspondre le titulaire du SPN à l’identité qui déchiffre le ticket ». Deux options sont possibles.

• Déchiffrer avec le compte machine (par défaut) : si le site est publié sous un nom d’hôte, enregistrer le SPN HTTP de ce nom d’hôte sur le compte machine.
• Déchiffrer avec l’identité du pool d’applications : activer useAppPoolCredentials, puis enregistrer le SPN HTTP sur le compte du pool d’applications.

Le choix dépend de si le même compte de service est partagé entre plusieurs serveurs (si c’est le cas, opter pour l’identité du pool est plus simple à gérer). Notez que le SPN ne peut être enregistré que sur un seul compte, donc en cas de bascule, n’oubliez pas de supprimer l’ancien enregistrement. Un double enregistrement casse l’authentification Kerberos elle-même.

Si votre conception fait usurper l’identité du client pour accéder à d’autres serveurs (délégation), le traitement diffère entre NTLM et Kerberos. Kerberos prend en charge un mécanisme de délégation permettant à un service de se connecter à un autre service pour le compte du client, alors que NTLM ne fournit que les informations d’autorisation nécessaires à une usurpation locale.⁸ L’implémentation autour de l’usurpation d’identité est traitée dans « Usurpation d’identité (impersonation) et jetons sous Windows ».

9. Feuille de route pour un resserrement progressif

Pour résumer tout cela, voici l’ordre de progression. La condition à chaque étape est de pouvoir « revenir en arrière ».

9.1. Arrêter SMB ne représente que la moitié du traitement de NTLM

Les étapes 4 à 6 ne traitent que SMB. Comme mentionné au chapitre 7, le blocage NTLM du client SMB est une fonctionnalité côté client SMB⁴ et n’a aucun effet sur les autres chemins. Ce qui a été classé à l’étape 2 comme « s’authentifie en HTTP », « SQL Server est en NTLM », « WinRM utilise NTLM » reste intact même une fois parvenu à l’étape 6. Et comme cela n’apparaît pas non plus dans la liste d’exceptions SMB, compter les entrées ne le révèle pas.

C’est l’étape 6b qui referme ce point. On utilise les trois mêmes stratégies que celles passées en mode audit au chapitre 4. La procédure suit la même forme.¹¹

1. En laissant « Trafic NTLM sortant vers des serveurs distants » sur « Tout auditer », recenser les destinations encore présentes
2. Enregistrer dans « Ajouter une exception de serveur distant » les correspondants absolument nécessaires
3. Basculer sur « Tout refuser » sur des postes pilotes et attendre qu’un cycle complet d’activité passe
4. Déployer si aucun problème n’apparaît

Pour l’ensemble du domaine, procédez de même avec « Authentification NTLM dans ce domaine », dans l’ordre audit → exception (« Ajouter une exception de serveur pour ce domaine ») → refus.¹² Microsoft indique lui aussi qu’avant de choisir l’option de refus, il faut configurer la stratégie d’audit correspondante sur la même option afin d’évaluer l’impact.¹²

Ce n’est pas parce que SMB est bloqué que le traitement de NTLM est terminé. Si vous voulez un indicateur d’achèvement, comptez à la fois la liste d’exceptions SMB et la liste d’exceptions serveur de Restrict NTLM.

9.2. Fixer la période d’audit non pas en « jours » mais en « cycle complet d’activité »

À l’étape 1, l’erreur la plus fréquente porte sur la façon de fixer la période. Si l’on conclut « c’est terminé, on a collecté pendant deux semaines », les traitements qui ne se sont pas exécutés pendant ces deux semaines n’apparaîtront pas dans la liste. Et ce qui n’y figure pas ne cassera qu’une fois le blocage déployé à l’étape 6.

Voici concrètement ce qui échappe facilement au filet.

• Les traitements de clôture mensuelle ou trimestrielle. Un exemple typique est un traitement par lot de fin de mois qui se connecte à un dossier partagé ou une base de données par adresse IP en dur.
• Les traitements annuels. Inventaire, changement d’exercice, opérations liées à la clôture comptable.
• Les chemins qui ne s’exécutent qu’en cas d’incident. Procédures de restauration depuis une sauvegarde, bascule vers un serveur de secours, exercices de reprise après sinistre (DR).
• Les postes hors ligne pendant longtemps. PC emportés à l’extérieur, poste d’un employé en congé prolongé, machine de secours habituellement éteinte.
• Les applications métier utilisées seulement quelques fois par an.

Le guide de Microsoft lui-même indique que l’analyse peut s’étendre sur plusieurs mois selon la complexité du déploiement.³ Une limite réaliste se situe dans l’une des deux options suivantes.

1. Continuer l’audit jusqu’à ce qu’un cycle complet d’activité soit passé. Au minimum une clôture mensuelle, si possible en couvrant un trimestre entier.
2. Recenser les traitements peu fréquents et les exécuter délibérément. Si l’on ne peut pas attendre aussi longtemps, faire tourner les traitements de clôture et les procédures DR en environnement de test et ajouter leurs résultats à la liste. Le point clé est de dresser au préalable, en interrogeant les responsables, la liste des traitements qui « n’apparaissent pas simplement parce qu’ils ne se sont pas exécutés ».

Dans les deux cas, avancez à l’étape suivante seulement une fois en mesure de distinguer « l’événement n’est pas apparu » de « ce n’est pas encore exécuté ».

9.3. Ne pas basculer d’un coup vers le refus

Ici, le point clé est de ne pas basculer d’un coup « Trafic NTLM sortant = Tout refuser ». Microsoft indique lui aussi que définir cette stratégie sur refus peut faire échouer de nombreuses demandes d’authentification NTLM et nuire à la productivité, et qu’avant de la mettre en œuvre, il faut examiner le journal avec « Tout auditer », analyser les serveurs, et constituer une liste d’exceptions à exclure.⁷ Un avertissement similaire figure pour la stratégie « Authentification NTLM dans ce domaine », qui s’applique à l’ensemble du domaine.¹²

10. Conclusion

• Toutes les versions de NTLM ont été dépréciées en juin 2024. Ce n’est pas un changement qui arrête tout immédiatement : NTLM continuera de fonctionner dans la prochaine version de Windows Server et la prochaine version annuelle de Windows.¹
• En revanche, NTLMv1 est déjà supprimé (Windows 11 24H2 / Windows Server 2025). Les appareils qui ne parlent qu’en NTLMv1 et les hôtes où NTLM V1 est enregistré représentent l’échéance la plus proche.¹
• La fin de NTLM se déroule en 3 phases : la phase 1 est l’audit, la phase 2 (seconde moitié de 2026) apporte IAKerb et le KDC local, la phase 3 est la désactivation par défaut.²
• L’audit consiste à passer trois stratégies en mode audit et à collecter Microsoft-Windows-NTLM/Operational. Pour un compte de domaine, en suivant l’ordre 8004 du DC → 8003 du serveur membre → 8001 du client, on arrive finalement jusqu’au nom de l’application. L’authentification par compte local ne fait pas apparaître le 8004, il faut donc la repérer via les événements du serveur et du client.³⁷
• Via SMB, le PID est toujours 4 (SYSTEM). Restreignez d’abord jusqu’au poste via les journaux d’événements, puis suivez ce seul poste avec ProcMon.³
• La cause principale, dans la majorité des cas, est un « nom ». Éliminer les adresses IP en dur et les SPN non enregistrés réduit considérablement le nombre d’exceptions restantes.³²
• NET USE \\server\share /BLOCKNTLM est le moyen de vérification le plus sûr : il permet de recouper sur une seule connexion, sans modifier aucune stratégie.⁴
• Pour les applications maison, remplacez les mentions explicites de NTLM par Negotiate, et uniformisez l’écriture des destinations sur le FQDN.⁵
• Une liste d’exceptions n’est pas une solution, c’est un sursis. Utilisez comme indicateur le fait que le nombre d’entrées diminue chaque année.

Articles connexes

• NTLM et Kerberos expliqués en images — Pourquoi l’authentification « retombe »-t-elle sur NTLM ?
• Les pièges des lecteurs réseau et des chemins UNC — gérer un serveur de fichiers (dossier partagé) dans une application métier
• Explorer les journaux d’événements avec Get-WinEvent en pratique — la vitesse du filtrage détermine le temps d’enquête
• Guide pratique de Process Monitor (ProcMon) — identifier en 10 minutes un « paramètre non lu » ou un « ACCESS DENIED »
• Introduction à PowerShell Remoting (WinRM) — administrer plusieurs postes Windows en une fois
• Gérer les informations d’identification en toute sécurité avec PowerShell — bannir les mots de passe en clair des scripts
• Intégrer l’authentification Entra ID dans une application WinForms/WPF — configuration pratique de MSAL.NET et du courtier WAM
• 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

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge le recensement des dépendances à NTLM, la modification des applications métier liée à la migration vers un environnement fondé sur Kerberos, ainsi que l’investigation des dysfonctionnements liés à l’authentification.

• 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.

Si NTLM est supprimé, à partir de quand mon activité va-t-elle s'arrêter ?

L'annonce de « dépréciation (deprecated) » à elle seule n'arrête rien. Microsoft a déprécié toutes les versions de NTLM en juin 2024, mais l'annonce précisait alors que « l'utilisation de NTLM continuera de fonctionner dans la prochaine version de Windows Server et dans la prochaine version annuelle de Windows ». Le changement concret qui a déjà cessé de fonctionner est la suppression de NTLMv1 dans Windows 11 version 24H2 et Windows Server 2025. Un projet de désactivation par défaut de NTLM réseau dans une future version a été annoncé, mais même à ce moment-là, il sera possible de le réactiver via une stratégie. Autrement dit, ce n'est pas le genre de changement où « toute l'entreprise s'arrête soudainement un jour », mais un resserrement progressif à chaque nouvelle version de l'OS. C'est précisément pour cela que la seule préparation réaliste consiste à recenser les dépendances via les journaux d'audit pendant que NTLM fonctionne encore, plutôt que d'enquêter après l'arrêt.

Comment puis-je dresser la liste des endroits où NTLM est utilisé ?

Passez les stratégies de groupe « Sécurité réseau : Restreindre NTLM » en mode audit et collectez le journal NTLM/Operational. En configurant « Auditer l'authentification NTLM dans ce domaine » sur les contrôleurs de domaine, et « Auditer le trafic NTLM entrant » ainsi que « Trafic NTLM sortant vers des serveurs distants = Auditer tout » sur les serveurs et les clients, les événements sont enregistrés dans l'Observateur d'événements sous « Journaux des applications et des services > Microsoft > Windows > NTLM ». Pour une authentification par compte de domaine, la méthode de suivi consiste à identifier l'utilisateur et le serveur de destination (nom du canal sécurisé) à partir de l'événement 8004 du contrôleur de domaine, puis à examiner l'ID de processus dans l'événement 8003 de ce serveur, et enfin à déterminer « quelle application, avec quel nom de serveur » a fait la demande grâce à l'événement 8001 du client. L'événement 8001 contient le nom du serveur cible et le nom du processus client, donc une fois arrivé là, l'application responsable est identifiée. Cependant, l'authentification par compte local ne passe pas par le contrôleur de domaine, donc l'événement 8004 n'apparaît pas. Pour les chemins où une machine en groupe de travail ou un compte local sur un serveur de fichiers se connecte à un partage, il faut les repérer via l'événement 8003 côté serveur et l'événement 8001 côté client. Ne concluez pas « chez nous, il y en a peu » en regardant uniquement les journaux du contrôleur de domaine.

Après avoir audité, le PID des événements est toujours 4 (SYSTEM) et je n'arrive pas à identifier l'application.

C'est parce que la communication passe par SMB (dossier partagé). L'authentification SMB est effectuée par le redirecteur en mode noyau, si bien que l'application appelante se cache derrière les paquets SMB, et le PID conservé dans l'événement est toujours 4 (SYSTEM). Le guide de Microsoft mentionne explicitement ce cas et indique comme solution d'exécuter Process Monitor (ProcMon) sur le client où l'événement apparaît, de filtrer le chemin par le nom d'ordinateur et l'adresse IP du serveur cible, puis de recouper avec l'horodatage de l'événement 8003 côté serveur pour identifier le processus appelant. En pratique, il est plus rapide de d'abord restreindre « quel poste » via les journaux d'événements, puis de ne suivre que ce poste avec ProcMon.

Pourquoi une application censée être compatible Kerberos retombe-t-elle sur NTLM ?

C'est presque toujours un problème de nom. Le guide de Microsoft cite quatre types d'applications qui, en théorie compatibles avec Kerberos, finissent par utiliser NTLM : les applications qui permettent de choisir la configuration de sécurité ou le fournisseur, les applications dont le SPN (nom de principal de service) n'est pas correctement enregistré, les applications qui se connectent par adresse IP plutôt que par nom DNS à cause d'une erreur de configuration ou de la documentation d'un fournisseur, et les applications dont la base de code héritée conserve une partie spécifique à NTLM. Si le « serveur cible » de l'événement 8001 n'est ni au format NetBIOS ni au format FQDN (c'est-à-dire une adresse IP), Kerberos n'est pas utilisé dans la configuration par défaut. Les deux premières actions à mener sont de remplacer une adresse IP en dur par un FQDN, et, si l'accès se fait sous un alias, d'enregistrer un SPN pour ce nom. Notez qu'il existe aussi une méthode pour les cas où il est vraiment impossible de passer à un nom — configurer TryIPSPN côté client et enregistrer manuellement un SPN pour l'adresse IP — mais Microsoft lui-même indique qu'elle ne doit être utilisée que lorsqu'il est impossible de basculer vers un nom DNS ; ce n'est donc qu'un dernier recours.

Que faut-il corriger dans une application Windows que nous développons nous-mêmes ?

Remplacez les endroits où le package d'authentification nomme explicitement NTLM par Negotiate. Microsoft indique clairement que « les applications ne devraient pas accéder directement au package de sécurité NTLM, mais utiliser le package 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. En .NET, la correction typique consiste à remplacer le type d'authentification passé à CredentialCache.Add de "NTLM" par "Negotiate" (c'est CredentialCache.Add qui précise le type d'authentification, pas le constructeur de NetworkCredential). Il faut aussi spécifier la destination par son FQDN plutôt que par une adresse IP ou un alias déclaré dans le fichier hosts, et, si vous voulez que votre propre service accepte Kerberos, enregistrer un SPN pour son compte de service.

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.