Auditer et restreindre NTLM dans Active Directory

Chaque authentification NTLM dans votre domaine est un relais potentiel, un hash potentiel à casser hors ligne et un identifiant qui peut être transmis sans connaître le mot de passe. La signature LDAP et SMB ferme des cibles de relais précises, mais la vraie correction consiste à cesser d'utiliser NTLM là où Kerberos fonctionne, et à le refuser là où rien de légitime n'en a besoin. Microsoft a déprécié NTLM en 2024, et Windows 11 24H2 et Windows Server 2025 n'incluent plus NTLMv1 : c'est le bon moment pour mesurer et réduire ce qui reste.

Ce guide développe la courte section « Restrict NTLM » du pilier NTLM et protocoles hérités en un programme complet : activer les bons paramètres d'audit, lire les événements 8001 à 8004, corriger les causes courantes, établir une liste d'exceptions qui reste courte, et supprimer NTLMv1 pour de bon.

Les stratégies Restrict NTLM

Tous les paramètres Restrict NTLM sont des Security Options, et non des modèles d'administration :

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > Security Options > Network security: Restrict NTLM: ...

Les événements sont écrits dans Applications and Services Logs > Microsoft > Windows > NTLM > Operational :

Lorsque vous passez un paramètre de l'audit au refus, le même journal enregistre les événements de blocage correspondants.

Étape 1 : mesurer le volume

Activez l'audit partout via une GPO qui ne contient que des valeurs d'audit. Le mode audit ne change rien au fonctionnement.

• Sur l'UO Domain Controllers : Audit NTLM authentication in this domain = Enable all, Audit Incoming NTLM Traffic = Enable auditing for all accounts.
• Sur tous les autres ordinateurs : Audit Incoming NTLM Traffic = Enable auditing for all accounts, Outgoing NTLM traffic to remote servers = Audit all.

Augmentez la taille du journal NTLM/Operational (l'événement 8004 est bavard sur les DC chargés) et centralisez-le avec Windows Event Forwarding. Collectez aussi les événements de sécurité 4776 (validation des identifiants) sur les DC et 4624 partout : l'événement 4624 enregistre le champ LmPackageName, qui indique si une ouverture de session a utilisé NTLM V1, NTLM V2 ou LM.

Étape 2 : traquer NTLMv1 en premier

Les réponses NTLMv1 peuvent être cassées rapidement jusqu'au hash NT du compte : NTLMv1 passe donc avant tout le reste. Recherchez-le sur les DC et les serveurs :

$xpath = "*[System[EventID=4624] and EventData[Data[@Name='AuthenticationPackageName']='NTLM'] and EventData[Data[@Name='LmPackageName']!='NTLM V2']]"
$dcs = (Get-ADDomainController -Filter *).HostName
foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -LogName Security -FilterXPath $xpath -MaxEvents 2000 -ErrorAction SilentlyContinue |
        ForEach-Object {
            $x = [xml]$_.ToXml(); $d = @{}
            $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
            [PSCustomObject]@{
                DC = $dc; User = "$($d.TargetDomainName)\$($d.TargetUserName)"
                Workstation = $d.WorkstationName; IP = $d.IpAddress; Package = $d.LmPackageName
            }
        }
} | Group-Object Workstation, User, Package | Sort-Object Count -Descending | Select-Object Count, Name

Écartez les ouvertures de session anonymes (LmPackageName = -) lors de l'analyse. Le vrai NTLMv1 provient généralement d'anciens équipements non Windows, de très vieux systèmes Windows, ou de machines dont une stratégie locale fixe LmCompatibilityLevel en dessous de 3.

Étape 3 : classer le NTLM observé

Synthétisez les événements 8004 des DC par serveur demandeur et par poste client :

foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -LogName 'Microsoft-Windows-NTLM/Operational' `
        -FilterXPath '*[System[EventID=8004]]' -MaxEvents 20000 -ErrorAction SilentlyContinue |
        ForEach-Object {
            $x = [xml]$_.ToXml(); $d = @{}
            $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
            [PSCustomObject]@{ Server = $d.SChannelName; User = $d.UserName; Client = $d.WorkstationName }
        }
} | Group-Object Server | Sort-Object Count -Descending | Select-Object Count, Name -First 50

Les noms de champs dans le XML de l'événement peuvent légèrement varier selon les versions de Windows ; examinez un événement avec $_.ToXml() et ajustez. Associez ensuite chaque paire serveur/client à une cause :

• Accès par adresse IP. Kerberos a besoin d'un SPN, et les clients n'essaient pas les SPN basés sur une IP par défaut. Modifiez le chemin, le mappage ou la configuration de l'application pour utiliser le nom DNS. Lorsqu'une IP est inévitable, Windows 10 et Server 2016 et versions ultérieures peuvent utiliser Kerberos avec un SPN d'IP enregistré sur le compte cible et la valeur de registre client TryIPSPN activée sous HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters.
• SPN manquants ou dupliqués, CNAME et noms de répartiteurs de charge. Enregistrez l'alias comme SPN sur le compte de service (setspn -S), et utilisez setspn -X pour trouver les doublons qui font échouer le KDC et provoquent le repli du client.
• Comptes locaux. L'utilisation à distance des comptes locaux passe toujours par NTLM. Avec Windows LAPS déployé, il s'agit surtout d'administrateurs ou d'outils qui utilisent des identifiants locaux à distance ; basculez-les sur des comptes de domaine du bon tier.
• Équipements hors domaine et en groupe de travail, appliances comprises. Décidez au cas par cas : jonction au domaine, passage à Kerberos (de nombreuses piles Linux et appliances le prennent en charge avec un keytab), ou acceptation en exception.
• Applications qui appellent explicitement NTLM au lieu de Negotiate. Elles nécessitent une correction de l'éditeur ou une exception.
• Accès inter-forêts sans approbation, ou via une approbation dont le routage des suffixes de noms est cassé. Corrigez le routage ou acceptez une exception.

Étape 4 : imposer par anneaux

Durcir le NTLM qui reste

Avant de bloquer, relevez le niveau d'exigence pour le NTLM encore autorisé. Ces paramètres peuvent être appliqués à tout le domaine une fois NTLMv1 disparu :

Network security: LAN Manager authentication level
  = Send NTLMv2 response only. Refuse LM & NTLM          (LmCompatibilityLevel = 5)
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients
  = Require NTLMv2 session security, Require 128-bit encryption
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers
  = Require NTLMv2 session security, Require 128-bit encryption
Network security: Do not store LAN Manager hash value on next password change = Enabled

LmCompatibilityLevel se trouve dans HKLM\SYSTEM\CurrentControlSet\Control\Lsa ; les deux valeurs de sécurité de session minimale sont NTLMMinClientSec et NTLMMinServerSec (537395200 pour les deux options) sous Lsa\MSV1_0. Appliquez d'abord le niveau 5 aux DC, puisque ce sont eux qui valident les comptes de domaine, puis à tout le reste.

Bloquer NTLM pour les identités et hôtes les plus sensibles

• Placez les comptes Tier 0 dans Protected Users ; ses membres ne peuvent pas du tout s'authentifier en NTLM.
• Interdisez Outgoing NTLM traffic to remote servers sur les postes d'administration privilégiés, afin que les identifiants d'administration n'en sortent jamais sous forme NTLM.
• Interdisez Incoming NTLM traffic sur les serveurs Tier 0 qui ne montrent aucun NTLM légitime dans les données d'audit.

Interdire NTLM dans le domaine, avec des exceptions

Une fois le volume de 8004 réduit à des sources connues et acceptées, réglez NTLM authentication in this domain sur les DC sur une valeur de refus et listez les serveurs restants dans Add server exceptions in this domain (un nom de serveur par ligne, caractères génériques autorisés). Commencez par « Deny for domain accounts to domain servers », qui laisse de côté le NTLM provenant de serveurs hors domaine, puis resserrez. Chaque exception doit avoir un responsable et une date de revue ; une liste d'exceptions qui ne fait que grossir n'est pas un contrôle.

Vérifier

• Le volume de 8004 sur les DC tend vers zéro en dehors des serveurs en exception ; les événements de blocage n'apparaissent que pour les sources que vous vouliez bloquer.
• La requête NTLMv1 sur 4624 de l'étape 2 ne renvoie rien.
• Contrôles de registre sur un échantillon d'hôtes :

Invoke-Command -ComputerName $dcs -ScriptBlock {
    [PSCustomObject]@{
        Host  = $env:COMPUTERNAME
        LmCompat = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa').LmCompatibilityLevel
        MinSrvSec = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0').NTLMMinServerSec
    }
}

• Un test avec un compte Protected Users sur un chemin par adresse IP doit échouer, tandis que le même chemin par nom DNS réussit en Kerberos (klist affiche un ticket pour le service).

Ce qui casse

• LmCompatibilityLevel 5 sur les DC casse tout ce qui envoie encore des réponses LM ou NTLMv1 : vieux copieurs et NAS, anciens clients SMB Unix et systèmes configurés en dur avec un niveau bas.
• La sécurité de session minimale casse les anciens clients et appliances incapables de négocier la sécurité de session NTLMv2 ou le chiffrement 128 bits.
• Interdire NTLM dans le domaine casse l'accès par IP, l'administration à distance par comptes locaux, les équipements en groupe de travail, certaines configurations VPN et Wi-Fi qui valident les utilisateurs via des protocoles basés sur NTLM, et les applications codées en dur pour NTLM, sauf si elles figurent dans la liste d'exceptions.
• Interdire le NTLM sortant sur les PAW casse les outils d'administration qui se connectent aux équipements par IP ou aux appliances hors domaine ; les administrateurs ont besoin d'un chemin distinct pour ceux-ci.
• Les membres de Protected Users perdent totalement NTLM : tout service qu'ils n'utilisent qu'en NTLM cesse de fonctionner pour eux.

Pour aller plus loin : le thème NTLM & protocoles hérités, Relais NTLM et Pass-the-hash pour ce que permet l'exposition NTLM, et Durcissement de Kerberos, car chaque flux NTLM supprimé devient un flux Kerberos qui doit utiliser AES.