Pourquoi Kerberos retombe en NTLM: diagnostic sur maquette

Le 29 janvier 2026, Microsoft a publié sur le blog Windows IT Pro sa feuille de route pour désactiver NTLM par défaut. La FAQ associée vise la prochaine version majeure de Windows Server et du client pour cette désactivation par défaut, avec la réserve que la date peut encore changer. Le 2 juin 2026, l’équipe a ajouté IAKerb et LocalKDC dans les builds Insider pour couvrir les cas où le client ne joint pas de contrôleur de domaine ou utilise des comptes locaux.

Le jour où le repli NTLM disparaît, chaque connexion qui retombait silencieusement en NTLM devient une connexion en échec. Pour identifier ces connexions, nous allons provoquer volontairement quatre pannes classiques sur une maquette et regarder à chaque fois la trace réseau, les tickets et les journaux.

Présentation de la maquette

Nous reprenons la maquette de l’article Configuration pas à pas de IIS8 pour l’utilisation du protocole KERBEROS, mise à jour avec des versions récentes:

• Nom du domaine: test.local (TESTLOCAL), contrôleur de domaine dc01.test.local
• Serveur IIS: srv01.test.local (192.168.0.102)
• Nom du site: monsite.test.local (enregistrement DNS de type A vers srv01)
• Compte de service du pool d’application: svc.monsite@test.local, avec useAppPoolCredentials="true"
• SPN: HTTP/monsite.test.local positionné sur svc.monsite
• Client: win11.test.local avec Edge, Fiddler en interception HTTPS et Wireshark

Côté contrôleur de domaine, la sous-catégorie d’audit « Validation des informations d’identification » doit être activée en succès, sinon l’événement 4776 dont nous allons nous servir n’apparaîtra jamais.

Kerberos ou NTLM? Le prouver

Trois endroits permettent de trancher, et ils doivent raconter la même histoire.

Le premier est l’entête « Authorization » vue dans Fiddler: un jeton commençant par YII est du Kerberos, un jeton commençant par TlRMTVNTUA est du NTLMSSP encodé en base64, comme nous l’avions détaillé dans l’article Exploration des entêtes HTTP WWW-Authenticate et Authorization.

Le deuxième est l’événement 4624 dans le journal Sécurité de srv01, section « Informations d’authentification détaillées ». Pour une connexion Kerberos:

Logon Type:               3
Logon Process:            Kerberos
Authentication Package:   Kerberos
Package Name (NTLM only): -
Key Length:               0

Et pour la même connexion retombée en NTLM:

Logon Type:               3
Logon Process:            NtLmSsp
Authentication Package:   NTLM
Package Name (NTLM only): NTLM V2
Key Length:               128

Le champ « Package Name (NTLM only) » donne le sous-package LAN Manager utilisé (NTLM V1, NTLM V2 ou LM) et n’est renseigné que si « Authentication Package » vaut NTLM. Attention: ce champ n’est pas parole d’évangile. Microsoft documente un cas où l’événement affiche NTLM V1 alors que la trace réseau montre du NTLMv2, à cause des drapeaux de sécurité de session négociés. Pour décider entre Kerberos et NTLM, c’est « Authentication Package » qui fait foi.

Pour ne sortir que les ouvertures de session NTLM sans parcourir tout le journal, une requête XPath suffit:

wevtutil qe Security /rd:true /c:5 /f:text /q:"*[System[(EventID=4624)] and EventData[Data[@Name='AuthenticationPackageName']='NTLM']]"

Le troisième est l’événement 4776 sur dc01. Pour un compte du domaine, srv01 transmet la réponse NTLM au contrôleur de domaine par NetLogon, et c’est dc01 qui la valide et la journalise avec « Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 », le compte et la station source. Une connexion Kerberos laisse à la place un 4769 (demande de ticket de service). Si nous voyons un 4776 pour notre utilisateur avec srv01 comme station au moment du test, le repli a eu lieu.

SPN absent ou dupliqué

Première panne, la plus fréquente: le SPN n’existe pas. Nous le retirons du compte de service, puis nous vidons le cache du client.

setspn -D HTTP/monsite.test.local TESTLOCAL\svc.monsite
klist purge

Nous relançons la connexion au site. Dans Wireshark, avec le filtre kerberos, la séquence s’arrête net:

-> TGS-REQ pour HTTP/monsite.test.local envoyé à dc01

-> KRB-ERROR en retour, code 7 (KDC_ERR_S_PRINCIPAL_UNKNOWN)

Le filtre kerberos.error_code == 7 isole ces réponses sur une capture longue. Dans Fiddler, l’entête « Authorization » suivante commence par TlRMTVNTUA, et le 4624 sur srv01 affiche NTLM. L’utilisateur, lui, ne voit rien: la page s’affiche, et personne ne signale le problème.

La commande klist get reproduit la demande de ticket sans navigateur:

C:\> klist get HTTP/monsite.test.local
Current LogonId is 0:0x3e1a4
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0xc000018b
klist failed with 0xc000018b/-1073741429: The SAM database on the Windows Server does not have a computer account for this workstation trust relationship.

Le message est trompeur, mais 0xc000018b est la traduction côté client de « principal inconnu ». Correction: setspn -S HTTP/monsite.test.local TESTLOCAL\svc.monsite.

Deuxième panne: le SPN est dupliqué. Nous ajoutons le même SPN sur le compte machine de srv01, en utilisant volontairement -A, qui ne contrôle pas les doublons (contrairement à -S):

setspn -A HTTP/monsite.test.local SRV01
setspn -Q HTTP/monsite.test.local
setspn -X

setspn -Q renvoie alors deux comptes, et setspn -X liste les doublons de toute la forêt. Sur dc01, le journal Système reçoit un événement 11 de la source Microsoft-Windows-Kerberos-Key-Distribution-Center qui signale un nom en double. Comme l’explique un billet de l’équipe Core Infrastructure de Microsoft, le KDC qui trouve deux comptes portant le même SPN journalise l’événement 11 et répond au client par une erreur de principal inconnu, et le client passe alors à NTLM. Dans la trace, la panne ressemble donc à la précédente. C’est setspn -Q et l’événement 11 qui font la différence.

Accès par IP ou par alias CNAME?

Troisième panne: l’utilisateur tape https://192.168.0.102. Cette fois, la capture Wireshark ne contient aucun TGS-REQ. Par défaut, Windows ne tente pas Kerberos quand le nom d’hôte est une adresse IP, et une application qui utilise une IP en dur retombe donc en NTLM. L’absence totale de dialogue avec le KDC suffit à reconnaître ce cas: le client n’a même pas essayé.

Depuis Windows 10 1507 et Windows Server 2016, il est possible d’autoriser des SPN contenant une adresse IP. Il faut une clé de registre sur chaque client et un SPN déclaré manuellement, comme le décrit la page Kerberos clients allow IPv4 and IPv6 address hostnames in SPNs:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" /v TryIPSPN /t REG_DWORD /d 1 /f
setspn -S HTTP/192.168.0.102 TESTLOCAL\svc.monsite

Microsoft réserve cette solution aux cas où il est impossible de passer à un nom DNS, parce qu’une adresse IP change au gré des baux DHCP. Je la garde pour les applications que l’on ne peut pas modifier.

Avec un CNAME, le repli est moins visible. Nous créons portail.test.local en CNAME vers srv01.test.local et nous ouvrons https://portail.test.local. Le SPN demandé dépend du client: les navigateurs Chromium (Edge, Chrome) résolvent par défaut le CNAME et construisent le SPN sur le nom canonique (comportement piloté par la stratégie DisableAuthNegotiateCnameLookup), alors que d’autres clients gardent le nom saisi. Plutôt que de deviner, nous demandons à klist ce qui a réellement été obtenu:

C:\> klist
#1>  Client: alice @ TEST.LOCAL
     Server: HTTP/srv01.test.local @ TEST.LOCAL
     KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

-> Le ticket vise HTTP/srv01.test.local, pas HTTP/portail.test.local.

Deux situations peuvent alors se présenter. Si aucun compte ne porte le SPN du nom demandé, nous retombons dans la première panne et donc en NTLM. Dans notre maquette, HTTP/srv01.test.local est couvert implicitement par HOST/srv01 sur le compte machine: le ticket est émis, mais chiffré avec la clé de srv01$. IIS tente de le déchiffrer avec la clé de svc.monsite (useAppPoolCredentials), échoue avec KRB_AP_ERR_MODIFIED, et l’utilisateur obtient une fenêtre d’authentification au lieu du SSO. La lecture du ticket avec klist et Wireshark est détaillée dans l’article Kerberos: lire un ticket de service avec klist et Wireshark. La correction la plus simple reste un enregistrement A dédié au site, avec le SPN correspondant sur le compte du pool.

Horloge et délégation

Quatrième panne: l’horloge. Sur srv01, nous arrêtons le service de temps et nous avançons l’horloge de dix minutes:

net stop w32time
Set-Date (Get-Date).AddMinutes(10)

Le client, lui, reste synchronisé sur dc01 et obtient son ticket de service sans difficulté: le TGS-REP est bien dans la trace. Le problème survient sur srv01, qui compare l’horodatage de l’authentificateur à sa propre heure et rejette l’AP-REQ avec KRB_AP_ERR_SKEW (code 37, RFC 4120), la tolérance par défaut du domaine étant de 5 minutes (stratégie « Tolérance maximale pour la synchronisation de l’horloge de l’ordinateur »). Cette erreur circule dans l’échange HTTP chiffré par TLS: nous ne la voyons pas dans Wireshark, mais dans le jeton Negotiate de la réponse 401 décodé dans Fiddler. Selon le client, le résultat est un échec ou une nouvelle tentative en NTLM. Le diagnostic se fait depuis srv01:

w32tm /query /status
w32tm /stripchart /computer:dc01.test.local /samples:3 /dataonly
net start w32time
w32tm /resync

Attention, la délégation n’est pas une cause de repli. Quand srv01 doit accéder pour le compte de l’utilisateur à un partage ou à une base sur un second serveur, l’échec du second saut n’est pas un repli NTLM en soi. Par contre, si le premier saut est passé en NTLM pour l’une des raisons ci dessus, srv01 ne détient aucun ticket de l’utilisateur et la délégation Kerberos classique devient impossible. Seule la délégation contrainte avec transition de protocole (« Utiliser n’importe quel protocole d’authentification ») s’en accommode. Avant de toucher aux paramètres de délégation du compte svc.monsite, nous regardons donc le 4624 du premier saut sur srv01.

En production, sur srv01, la stratégie « Sécurité réseau: Restreindre NTLM: Auditer le trafic NTLM entrant » en mode audit alimente le journal Microsoft-Windows-NTLM/Operational sans rien bloquer. Croisé avec les 4776 de dc01, ce journal donne la liste des applications et des postes qui dépendent encore de NTLM.

Rémi Vernier

Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.

Tous les articles → LinkedIn →