Kerberos et NTLM : comprendre l'authentification Windows

Kerberos et NTLM sont les deux protocoles qui authentifient les utilisateurs et les machines d'un domaine Windows. Kerberos, le protocole par défaut, délivre des tickets chiffrés par le contrôleur de domaine ; NTLM, plus ancien, prouve la connaissance du mot de passe par un défi-réponse. Pour défendre un annuaire, il faut savoir où se trouvent les secrets que ces protocoles manipulent, car presque toutes les attaques du chapitre 3 consistent à voler, deviner ou réutiliser l'un d'eux.

Le secret de départ : l'empreinte NT

Active Directory ne stocke pas les mots de passe en clair. Pour chaque compte, il conserve des clés dérivées du mot de passe, dans la base NTDS.dit de chaque contrôleur de domaine :

L'empreinte NT a deux défauts. Sans sel, deux comptes qui ont le même mot de passe ont la même empreinte, sur toutes les machines. Et surtout, l'empreinte suffit pour s'authentifier en NTLM ou en Kerberos RC4 : celui qui la vole n'a pas besoin du mot de passe. C'est le fondement du pass-the-hash. Les clés AES, salées et lentes à calculer, résistent beaucoup mieux au cassage hors ligne, d'où l'intérêt de supprimer RC4 (chapitre 8).

Ces clés existent aussi ailleurs que sur les contrôleurs :

• dans la base SAM de chaque machine, pour ses comptes locaux (dont l'Administrateur local) ;
• dans la mémoire du processus LSASS d'une machine, pour les comptes qui y ont ouvert une session, tant que la session dure (et parfois après) ;
• dans le cache des ouvertures de session des postes, sous une forme dérivée qui permet de se connecter sans contrôleur de domaine (10 sessions par défaut) : cette forme ne permet pas le pass-the-hash, mais peut être cassée hors ligne.

NTLM : un défi-réponse fondé sur l'empreinte

NTLM (NT LAN Manager) authentifie par défi-réponse, sans faire circuler le mot de passe ni l'empreinte. Quand Julie ouvre \\srv-fichiers\compta par son adresse IP ou depuis une machine hors domaine, l'échange est le suivant :

1. NEGOTIATE : le client annonce les options qu'il sait gérer.
2. CHALLENGE : le serveur renvoie un défi aléatoire.
3. AUTHENTICATE : le client calcule une réponse à partir du défi, d'un défi client, de l'heure et de l'empreinte NT, puis l'envoie avec le nom du compte.
4. Le serveur, qui ne connaît pas les secrets des comptes du domaine, transmet défi et réponse au contrôleur de domaine par le canal sécurisé Netlogon : c'est l'authentification directe (pass-through).
5. Le contrôleur refait le calcul avec l'empreinte qu'il détient, compare et répond. Il écrit l'événement 4776 dans son journal Sécurité.

Pour un compte local (l'Administrateur local d'un poste), c'est la machine cible qui vérifie elle-même la réponse avec sa base SAM : le contrôleur de domaine n'en voit rien. Un déplacement latéral avec le compte d'administrateur local ne laisse donc aucune trace sur les contrôleurs, seulement sur les machines visées.

Les faiblesses de NTLM, qui expliquent qu'on cherche à s'en passer :

• l'empreinte suffit : la réponse se calcule sans le mot de passe ;
• pas d'authentification du serveur : le client ne sait pas à qui il parle, ce qui permet de relayer l'échange vers un autre serveur, sauf si la signature des échanges (SMB, LDAP) est exigée ;
• NTLMv1 utilisait une cryptographie si faible que la réponse permettait de retrouver l'empreinte. Microsoft l'a supprimé de Windows 11 24H2 et de Windows Server 2025, et a déclaré toutes les versions de NTLM obsolètes. NTLMv2 reste présent et actif par défaut ; Microsoft prévoit de désactiver NTLM sur le réseau par défaut dans une prochaine version de Windows Server, après une phase d'audit disponible dès Windows Server 2025.

Kerberos : des tickets chiffrés par le contrôleur de domaine

Le cours Authentification explique les cinq échanges de Kerberos. Ici, on les reprend avec la question du défenseur : quelle clé chiffre quoi ?

Trois notions à bien maîtriser :

Le SPN (Service Principal Name) est le nom sous lequel un service est connu de Kerberos, par exemple MSSQLSvc/srv-gestion.ad.sorbier.example:1433 ou HTTP/intranet.ad.sorbier.example. Il est enregistré sur le compte qui fait tourner le service. Quand ce compte est un compte d'ordinateur, sa clé vient d'un mot de passe aléatoire de 120 caractères changé tous les 30 jours : le ticket est incassable. Quand c'est un compte utilisateur créé à la main pour le service (svc-sauvegarde), sa clé vient d'un mot de passe humain, souvent ancien : le ticket devient une cible.

Le compte krbtgt est un compte désactivé, créé avec le domaine, dont la seule fonction est de porter la clé qui chiffre et signe tous les TGT. Son mot de passe ne change jamais tout seul. Il garde en mémoire son mot de passe actuel et le précédent, pour que les tickets en cours restent valides pendant un changement : c'est pourquoi on le change deux fois après une compromission (chapitre 7).

L'heure. Kerberos refuse un horodatage décalé de plus de 5 minutes par rapport au contrôleur. Une dérive d'horloge se manifeste par des échecs de pré-authentification avec le code 0x25 (clock skew too great), et non par un mauvais mot de passe.

Les valeurs par défaut de la stratégie Kerberos du domaine : TGT valable 10 heures, renouvelable pendant 7 jours, ports TCP et UDP 88 (et 464 pour le changement de mot de passe). Pour les membres de Protected Users, le TGT est limité à 4 heures, sans renouvellement au-delà.

RC4 ou AES : le type de chiffrement d'un ticket

Chaque ticket porte un type de chiffrement, visible dans l'événement 4769 du contrôleur :

RC4 était encore accepté par défaut pour les comptes sans réglage explicite jusqu'en 2026. Microsoft l'a retiré par étapes : depuis les mises à jour d'avril 2026, les contrôleurs de domaine n'émettent plus par défaut que des tickets AES pour les comptes dont l'attribut msDS-SupportedEncryptionTypes n'est pas renseigné, et depuis juillet 2026 le retour en arrière par le registre n'est plus possible. Le chapitre 8 montre comment repérer les comptes et les applications qui exigent encore RC4. Pour le défenseur, un ticket 0x17 demandé pour un compte de service est désormais anormal et mérite une alerte.

Quand Windows utilise NTLM au lieu de Kerberos

Les applications Windows appellent en général le mécanisme Negotiate, qui essaie Kerberos d'abord et retombe sur NTLM si Kerberos est impossible. Les cas de repli les plus courants :

Ce tableau sert directement au durcissement : avant de restreindre NTLM, il faut trouver qui l'utilise et pourquoi (chapitre 8).

La délégation Kerberos

La délégation permet à un service d'agir au nom de l'utilisateur auprès d'un autre service : un site intranet qui interroge une base SQL Server avec l'identité de l'utilisateur connecté. C'est utile, et c'est un risque connu.

Deux réglages protègent un compte de toute délégation : l'option « Le compte est sensible et ne peut pas être délégué » et l'appartenance au groupe Protected Users. On les applique aux comptes d'administration (chapitre 5).

Où regarder : les traces de chaque protocole

Ces événements ne sont écrits que si la stratégie d'audit les demande ; le chapitre 9 donne les réglages et les lectures types.

Exercices

Exercice 1 sur 4 Quelle clé chiffre quoi ? Réussi À revoir

Pour chacun de ces éléments, donne la clé qui le chiffre (ou le signe), puis dis qui doit la détenir pour le lire :

1. le TGT de Julie Lefèvre ;
2. le ticket de service que Julie présente à srv-gestion pour l'application de gestion ;
3. l'horodatage de pré-authentification envoyé par le poste de Julie ;
4. la réponse NTLM envoyée par le poste de Julie à srv-fichiers.

Voir la réponseMasquer la réponse de l'exercice 1

1. La clé du compte krbtgt. Seul le KDC (les contrôleurs de domaine) la détient : le poste de Julie ne peut pas lire son propre TGT, il le présente tel quel.
2. La clé du compte qui porte le SPN de l'application, ici le compte d'ordinateur srv-gestion$ si le service tourne sous un compte système. Le serveur la détient et déchiffre le ticket. Si le service tournait sous un compte utilisateur dédié, ce serait la clé de ce compte.
3. La clé de Julie, dérivée de son mot de passe. Le contrôleur la détient (dans NTDS.dit) et vérifie l'horodatage.
4. La réponse est calculée avec l'empreinte NT de Julie, elle n'est pas « chiffrée » pour un destinataire. srv-fichiers ne peut pas la vérifier seul : il la transmet au contrôleur, qui détient l'empreinte et refait le calcul.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Kerberos ou NTLM ? Réussi À revoir

Pour chaque situation, dis si l'authentification se fera en Kerberos ou en NTLM, et justifie.

1. Chloé ouvre \\srv-fichiers.ad.sorbier.example\scripts depuis son poste du domaine.
2. Un script de sauvegarde lance net use \\192.168.10.178\sauvegardes.
3. Moussa se connecte à l'interface d'administration d'une imprimante avec son compte du domaine, via une authentification Windows intégrée configurée sans SPN.
4. Antoine ouvre une session sur un poste du domaine alors que le câble réseau est débranché.

Voir la réponseMasquer la réponse de l'exercice 2

1. Kerberos : le poste est dans le domaine, le nom complet correspond au SPN cifs/srv-fichiers.ad.sorbier.example porté par le compte d'ordinateur du serveur.
2. NTLM : l'adresse IP ne correspond à aucun SPN, Negotiate retombe sur NTLM. Correction : utiliser le nom du serveur dans le script.
3. NTLM : sans SPN, le KDC ne peut pas délivrer de ticket pour ce service.
4. Aucun des deux sur le réseau : sans contrôleur joignable, Windows vérifie le mot de passe avec le cache des ouvertures de session du poste (si Antoine s'y est déjà connecté). C'est justement ce cache que le sujet 2024 (épreuve alors appelée E6) jugeait dangereux pour les comptes d'administration : il laisse sur le poste une forme dérivée du mot de passe, cassable hors ligne.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Pourquoi les comptes d'ordinateurs résistent au Kerberoasting Réussi À revoir

N'importe quel compte du domaine peut demander un ticket de service pour cifs/srv-fichiers.ad.sorbier.example comme pour MSSQLSvc/srv-gestion.ad.sorbier.example:1433 (porté par le compte utilisateur svc-sql). Explique pourquoi le premier ticket n'intéresse pas un attaquant, alors que le second l'intéresse beaucoup.

Voir la réponseMasquer la réponse de l'exercice 3

Un ticket de service est chiffré avec la clé du compte qui porte le SPN. Le premier SPN est porté par le compte d'ordinateur srv-fichiers$, dont le mot de passe est généré aléatoirement par la machine (120 caractères) et changé automatiquement tous les 30 jours : le casser hors ligne est hors de portée. Le second est porté par un compte utilisateur svc-sql, dont le mot de passe a été choisi par un humain, souvent court, rarement changé : l'attaquant peut essayer des milliards de mots de passe par seconde contre le ticket, sur sa propre machine, sans aucune trace sur le réseau après la demande initiale. Parade : un compte de service géré (gMSA), dont le mot de passe est aussi long et aussi souvent renouvelé que celui d'un ordinateur (chapitre 7), et le chiffrement AES.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Délégation non contrainte Réussi À revoir

L'audit montre que l'ordinateur srv-gestion est configuré en « délégation non contrainte » (attribut TRUSTED_FOR_DELEGATION). Explique le risque, en supposant qu'Antoine, administrateur du domaine, ouvre une session sur l'application de srv-gestion, puis propose deux mesures.

Voir la réponseMasquer la réponse de l'exercice 4

Risque. Avec la délégation non contrainte, chaque utilisateur qui s'authentifie auprès de srv-gestion lui transmet une copie de son TGT, que le serveur garde en mémoire pour agir en son nom auprès de n'importe quel service. Si srv-gestion est compromis (c'est un serveur de tier 1, plus exposé que les contrôleurs), l'attaquant récupère le TGT d'Antoine et l'utilise pour accéder aux contrôleurs de domaine avec ses droits : un serveur de tier 1 devient un chemin vers le tier 0.

Mesures.

1. Remplacer la délégation non contrainte par une délégation contrainte limitée au seul service nécessaire (par exemple la base SQL utilisée par l'application), ou la supprimer si elle n'est pas utile.
2. Protéger les comptes d'administration contre toute délégation : option « Le compte est sensible et ne peut pas être délégué » et appartenance au groupe Protected Users. Et surtout, Antoine n'utilise pas un compte de tier 0 pour ouvrir une application de tier 1 (chapitre 5).

Tu avais trouvé ?

Oui, j'avais bonPas encore