Date de publication d’origine : 11 juillet 2025
ID de la base de connaissances : 5064479
Contenu de cet article :
Introduction
Cet article fournit une vue d’ensemble des modifications à venir apportées à la fonctionnalité d’audit NT LAN Manager (NTLM) dans Windows 11, version 24H2 et Windows Server 2025. Ces améliorations sont conçues pour améliorer la visibilité de l’activité d’authentification NTLM, ce qui permet aux administrateurs de déterminer l’identité des utilisateurs, la justification de l’utilisation de NTLM et les emplacements spécifiques où NTLM est utilisé dans un environnement. L’audit amélioré prend en charge l’amélioration de la surveillance de la sécurité et l’identification des dépendances d’authentification héritées.
Objectif des modifications d’audit NTLM
L’authentification NTLM continue d’être présente dans différents scénarios d’entreprise, souvent en raison d’applications et de configurations héritées. Avec l’annonce de la dépréciation et de la désactivation future de NTLM (voir le blog informatique Windows L’évolution de Authentification Windows), les fonctionnalités d’audit mises à jour sont destinées à aider les administrateurs à identifier l’utilisation de NTLM, à comprendre les modèles d’utilisation et à détecter les risques potentiels pour la sécurité, y compris l’utilisation de NT LAN Manager version 1 (NTLMv1).
Journaux d’audit NTLM
Windows 11, version 24H2 et Windows Server 2025 introduisent de nouvelles fonctionnalités de journalisation d’audit NTLM pour les clients, les serveurs et les contrôleurs de domaine. Chaque composant génère des journaux qui fournissent des informations détaillées sur les événements d’authentification NTLM. Ces journaux se trouvent dans observateur d'événements sous Journaux des applications et des services > Microsoft > Windows > NTLM > Opérationnel.
Par rapport aux journaux d’audit NTLM existants, les nouvelles modifications d’audit améliorées permettent aux administrateurs de répondre aux questions Qui, Pourquoi et Où :
-
Qui utilise NTLM, y compris le compte et le processus sur l’ordinateur.
-
Pourquoi l’authentification NTLM a été choisie, au lieu des protocoles d’authentification modernes comme Kerberos.
-
Où se produit l’authentification NTLM, y compris le nom de l’ordinateur et l’adresse IP de l’ordinateur.
L’audit NTLM amélioré fournit également des informations sur l’utilisation de NTLMv1 pour les clients et les serveurs, ainsi que sur l’utilisation de NTLMv1 enregistrée à l’échelle du domaine par le contrôleur de domaine.
Gestion des stratégies de groupe
Les nouvelles fonctionnalités d’audit NTLM sont configurables via des paramètres de stratégie de groupe mis à jour. Les administrateurs peuvent utiliser ces stratégies pour spécifier les événements d’authentification NTLM qui sont audités et pour gérer le comportement d’audit sur les clients, les serveurs et les contrôleurs de domaine en fonction de leur environnement.
Par défaut, les événements sont activés.
-
Pour la journalisation du client et du serveur, les événements sont contrôlés par le biais de la stratégie « Journalisation améliorée NTLM » sous Modèles d’administration > Système > NTLM.
-
Pour la journalisation à l’échelle du domaine sur le contrôleur de domaine, les événements sont contrôlés par le biais de la stratégie « Journaux NTLM améliorés à l’échelle du domaine » sous Modèles d’administration > Système > Netlogon.
Niveaux d’audit
Chaque journal d’audit NTLM est divisé en deux ID d’événement différents avec les mêmes informations qui diffèrent uniquement par niveau d’événement :
-
Informations : indique des événements NTLM standard, tels que l’authentification NT LAN Manager version 2 (NTLMv2), où aucune réduction de la sécurité n’est détectée.
-
Avertissement : indique une rétrogradation de la sécurité NTLM, telle que l’utilisation de NTLMv1. Ces événements mettent en évidence l’authentification non sécurisée. Un événement peut être marqué comme un « Avertissement » pour des instances telles que les suivantes :
-
Utilisation de NTLMv1 détectée par le client, le serveur ou le contrôleur de domaine.
-
La protection renforcée pour l’authentification est marquée comme non prise en charge ou non sécurisée (pour plus d’informations, consultez KB5021989 : Protection étendue pour l’authentification).
-
Certaines fonctionnalités de sécurité NTLM, telles que le case activée d’intégrité des messages (MIC), ne sont pas utilisées.
-
Journaux du client
Les nouveaux journaux d’audit enregistrent les tentatives d’authentification NTLM sortantes. Ces journaux fournissent des détails sur les applications ou services à l’origine des connexions NTLM, ainsi que les métadonnées pertinentes pour chaque demande d’authentification.
La journalisation du client a un champ unique, Id d’utilisation/Raison, qui met en évidence la raison pour laquelle l’authentification NTLM a été utilisée.
ID |
Description |
0 |
Raison inconnue. |
1 |
NTLM a été appelé directement par l’application appelante. |
2 |
Authentification d’un compte local. |
3 |
RÉSERVÉ, actuellement non utilisé. |
4 |
Authentification d’un compte cloud. |
5 |
Le nom de la cible était manquant ou vide. |
6 |
Le nom de la cible n’a pas pu être résolu par Kerberos ou d’autres protocoles. |
7 |
Le nom cible contient une adresse IP. |
8 |
Le nom de la cible a été dupliqué dans Active Directory. |
9 |
Aucune ligne de vue n’a pu être établie avec un contrôleur de domaine. |
10 |
NTLM a été appelé via une interface de bouclage. |
11 |
NTLM a été appelé avec une session null. |
Journal des événements |
Microsoft-Windows-NTLM/Operational |
ID d’événement |
4020 (Informations), 4021 (Avertissement) |
Source de l’événement |
NTLM |
Texte de l’événement |
Cet ordinateur a tenté de s’authentifier auprès d’une ressource distante via NTLM. Informations sur les processus : Nom du processus : nom <> PROCESSUS PID :> PID < Informations sur le client : Nom d’utilisateur : <nom d’utilisateur> Domaine : <nom de domaine> Nom d’hôte :> nom d’hôte < type de Sign-On : <Sign-On unique/> creds fournis Informations sur la cible : Machine cible : <nom de l’ordinateur> Domaine cible : <> domaine de l’ordinateur Ressource cible : nom du principal du service (SPN) <> Adresse IP cible :> d’adresse IP < Nom du réseau cible : <nom du réseau> Utilisation de NTLM : ID de raison : <id d’utilisation> Motif : <raison de l’utilisation> Sécurité NTLM : Indicateurs négociés : indicateurs <> Version de NTLM : <NTLMv2/NTLMv1> État de la clé de session : < présent/> manquant Liaison de canal : <> pris en charge/non pris en charge Liaison de service : <nom du principal du service (SPN) > État mic : < protégé/non protégé> AvFlags : <indicateurs NTLM> Chaîne AvFlags : <chaîne d’indicateur NTLM> Pour plus d’informations, consultez aka.ms/ntlmlogandblock. |
Journaux du serveur
Les nouveaux journaux d’audit enregistrent les tentatives d’authentification NTLM entrantes. Ces journaux fournissent des détails similaires sur l’authentification NTLM que les journaux du client, et indiquent si l’authentification NTLM a réussi ou non.
Journal des événements |
Microsoft-Windows-NTLM/Operational |
ID d’événement |
4022 (informations), 4023 (avertissement) |
Source de l’événement |
NTLM |
Texte de l’événement |
Un client distant utilise NTLM pour s’authentifier auprès de cette station de travail. Informations sur les processus : Nom du processus : nom <> PROCESSUS PID :> PID < Informations sur le client distant : Nom d’utilisateur : <nom d’utilisateur du client> Domaine :> de domaine client < Ordinateur client : <nom de l’ordinateur client> Adresse IP du client :> ip du client < Nom du réseau client : <nom réseau du client> Sécurité NTLM : Indicateurs négociés : indicateurs <> Version de NTLM : <NTLMv2/NTLMv1> État de la clé de session : < présent/> manquant Liaison de canal : <> pris en charge/non pris en charge Liaison de service : <nom du principal du service (SPN) > État mic : < protégé/non protégé> AvFlags : <indicateurs NTLM> Chaîne AvFlags : <chaîne d’indicateur NTLM> État : <code d’état> Message d’état : <chaîne d’état> Pour plus d’informations, consultez aka.ms/ntlmlogandblock |
Journaux du contrôleur de domaine
Les contrôleurs de domaine bénéficient d’un audit NTLM amélioré, avec de nouveaux journaux qui capturent les tentatives d’authentification NTLM réussies et infructueuses pour l’ensemble du domaine. Ces journaux prennent en charge l’identification de l’utilisation NTLM inter-domaines et alertent les administrateurs en cas de rétrogradations potentielles dans la sécurité de l’authentification, telles que l’authentification NTLMv1.
Différents journaux d’activité de contrôleur de domaine sont créés en fonction des scénarios suivants :
Lorsque le compte client et l’ordinateur serveur appartiennent au même domaine, un journal semblable à ce qui suit est créé :
Journal des événements |
Microsoft-Windows-NTLM/Operational |
ID d’événement |
4032 (informations), 4033 (avertissement) |
Source de l’événement |
Security-Netlogon |
Texte de l’événement |
Le contrôleur de domaine <nom du contrôleur de domaine> traité une demande d’authentification NTLM transférée provenant de ce domaine. Informations sur le client : Nom du client : <nom d’utilisateur> Domaine client :> de domaine < Ordinateur client :> de station de travail cliente < Informations sur le serveur : Nom du serveur : nom de l’ordinateur du serveur <> Domaine du serveur :> domaine <Server Adresse IP du serveur : <> IP du serveur Système d’exploitation serveur :> du système d’exploitation <Server Sécurité NTLM : Indicateurs négociés : indicateurs <> Version de NTLM : <NTLMv2/NTLMv1> État de la clé de session : < présent/> manquant Liaison de canal : <> pris en charge/non pris en charge Liaison de service : <nom du principal du service (SPN) > État mic : < protégé/non protégé> AvFlags : <indicateurs NTLM> Chaîne AvFlags : <chaîne d’indicateur NTLM> État : <code d’état> Message d’état : <chaîne d’état> Pour plus d’informations, consultez aka.ms/ntlmlogandblock |
Si le compte client et le serveur appartiennent à des domaines différents, le contrôleur de domaine aura des journaux différents selon que le contrôleur de domaine appartient au domaine où réside le client (à l’origine de l’authentification) ou à l’endroit où réside le serveur (en acceptant l’authentification) :
Si le serveur appartient au même domaine que le contrôleur de domaine qui gère l’authentification, un journal similaire au « Journal du même domaine » est créé.
Si le compte client appartient au même domaine que le contrôleur de domaine qui gère l’authentification, un journal semblable à ce qui suit est créé :
Journal des événements |
Microsoft-Windows-NTLM/Operational |
ID d’événement |
4030 (informations), 4031 (avertissement) |
Source de l’événement |
Security-Netlogon |
Texte de l’événement |
Le contrôleur de domaine <nom du contrôleur de domaine> traité une demande d’authentification NTLM transférée provenant de ce domaine. Informations sur le client : Nom du client : <nom d’utilisateur> Domaine client :> de domaine < Ordinateur client :> de station de travail cliente < Informations sur le serveur : Nom du serveur : nom de l’ordinateur du serveur <> Domaine du serveur :> domaine <Server Transféré à partir de : Type de canal sécurisé : <Netlogon Secure Channel Info> Nom farside : <nom de la machine de contrôleur de domaine inter-domaines > Domaine farside : <nom de domaine inter-domaines> Adresse IP farside : <> ip du contrôleur de domaine inter-domaines Sécurité NTLM : Indicateurs négociés : indicateurs <> Version de NTLM : <NTLMv2/NTLMv1> État de la clé de session : < présent/> manquant Liaison de canal : <> pris en charge/non pris en charge Liaison de service : <nom du principal du service (SPN) > État mic : < protégé/non protégé> AvFlags : <indicateurs NTLM> Chaîne AvFlags : <chaîne d’indicateur NTLM> État : <code d’état> Pour plus d’informations, consultez aka.ms/ntlmlogandblock |
Relation entre les événements NTLM nouveaux et existants
Les nouveaux événements NTLM sont une amélioration par rapport aux journaux NTLM existants, comme Sécurité réseau : Restreindre l’authentification NTLM Audit NTLM dans ce domaine. Les modifications d’audit NTLM améliorées n’affectent pas les journaux NTLM actuels ; si les journaux d’audit NTLM actuels sont activés, ils continueront d’être enregistrés.
Informations de déploiement
Conformément au déploiement des fonctionnalités contrôlées par Microsoft (CFR), les modifications seront d’abord déployées progressivement sur les machines Windows 11, version 24H2, puis sur les machines Windows Server 2025, y compris les contrôleurs de domaine.
Un déploiement progressif distribue une mise à jour de mise en production sur une période donnée, plutôt que tout à la fois. Cela signifie que les utilisateurs reçoivent les mises à jour à différents moments et qu’elles peuvent ne pas être immédiatement disponibles pour tous les utilisateurs.