Durcir le domaine : NTLM, LLMNR, SMBv1, signatures et RC4

Durcir un domaine, c'est fermer les portes que des protocoles anciens, gardés pour la compatibilité, laissent ouvertes : NTLM, LLMNR et NetBIOS, SMBv1, les échanges non signés, le chiffrement RC4. Chacun est une faiblesse connue, exploitée par les attaques du chapitre 3. Ce chapitre explique le risque de chacun et la mesure qui le ferme, en suivant toujours la même prudence : auditer avant de restreindre, pour ne pas couper un service qui en dépend encore.

La méthode : auditer, puis restreindre

Un durcissement brutal casse des applications et retombe sur le service informatique. La bonne démarche, pour chaque protocole :

1. Auditer : activer le journal qui enregistre les usages, laisser tourner quelques semaines, repérer qui utilise le protocole et pourquoi.
2. Corriger les dépendances : mettre à jour ou reconfigurer les applications et équipements concernés.
3. Restreindre par étapes, en commençant par un périmètre de test, en gardant une porte de secours.
4. Vérifier que plus personne n'utilise le protocole, puis le couper.

NTLM : auditer puis restreindre

NTLM (chapitre 2) est vulnérable au pass-the-hash et au relais. Microsoft l'a déclaré obsolète et prévoit de le désactiver sur le réseau par défaut dans une prochaine version de Windows Server ; en attendant, on le restreint.

NTLMv1 a été supprimé de Windows 11 24H2 et de Windows Server 2025 : ces systèmes ne l'acceptent plus. Il reste des traces de sa cryptographie dans certains scénarios (l'authentification MS-CHAPv2 du Wi-Fi ou du VPN par exemple) ; Microsoft les ferme par le réglage BlockNtlmv1SSO, dont la valeur par défaut passe en mode blocage avec la mise à jour d'octobre 2026 sur les systèmes éligibles.

NTLMv2 reste présent et actif. On procède par l'audit, avec les stratégies Sécurité réseau : restreindre NTLM (Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité) :

Le réglage niveau d'authentification LAN Manager (LmCompatibilityLevel) doit être à « Envoyer uniquement des réponses NTLMv2, refuser LM et NTLM » (valeur 5) : il interdit les versions les plus faibles. Le groupe Protected Users (chapitre 5) refuse déjà NTLM pour ses membres : c'est la première restriction à poser, sur les comptes d'administration.

LLMNR et NetBIOS : couper les résolutions de secours

Quand un poste ne résout pas un nom par le DNS, Windows essaie, par défaut, deux mécanismes de secours qui diffusent la question à tout le réseau local : LLMNR (Link-Local Multicast Name Resolution) et NetBIOS sur TCP/IP. Un attaquant sur le même réseau répond « c'est moi » à ces questions et capture l'authentification NTLM du poste, qu'il peut relayer. C'est l'empoisonnement LLMNR/NBT-NS, l'un des premiers gestes d'un attaquant interne. Ces mécanismes ne servent presque jamais dans un domaine, où le DNS d'Active Directory fait le travail.

Couper LLMNR par GPO : Configuration ordinateur > Stratégies > Modèles d'administration > Réseau > Client DNS > Désactiver la résolution de noms multidiffusion (Turn off multicast name resolution) → Activé.

Couper NetBIOS sur TCP/IP : historiquement via les options DHCP ou les propriétés de la carte réseau. Depuis Windows 11 24H2 et Windows Server 2025, une GPO le règle proprement : Réseau > Paramètres NetBT > Configurer NetBIOS → désactivé. On vérifie ensuite qu'aucune application ancienne ne dépend de la résolution NetBIOS (partages désignés par un nom court non qualifié, vieux logiciels).

SMBv1 et la signature SMB

SMBv1 est la version du protocole de partage de fichiers exploitée par le ver WannaCry en 2017. Elle ne doit plus être installée ; elle ne l'est plus par défaut depuis Windows 10 1709 et Windows Server 2019. On vérifie son absence :

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select-Object State
# Si Enabled, la désinstaller :
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

La signature SMB empêche de relayer ou de modifier un échange de partage : chaque paquet est signé. Depuis Windows 11 24H2 (éditions Professionnel, Entreprise et Éducation), la signature est exigée par défaut pour les connexions SMB sortantes et entrantes ; Windows Server 2025 ne l'exige par défaut que pour les connexions sortantes (avant, elle ne l'était que pour les partages SYSVOL et NETLOGON des contrôleurs). Sur les serveurs de fichiers comme srv-fichiers, on l'exige donc par GPO côté serveur : Options de sécurité > Serveur réseau Microsoft : communications signées numériquement (toujours) → Activé. Côté client, le réglage symétrique est Client réseau Microsoft : communications signées numériquement (toujours), utile sur les postes plus anciens. Vérification sur le serveur : Get-SmbServerConfiguration | Format-List RequireSecuritySignature.

La signature LDAP et la liaison de canal

Les contrôleurs de domaine répondent aux requêtes LDAP sur le port 389. Sans signature, un attaquant peut relayer ou modifier ces échanges. Deux protections :

• la signature LDAP (LDAP server signing requirements), qui signe les échanges ;
• la liaison de canal LDAP (channel binding), qui lie l'authentification au canal TLS, contre le relais vers LDAPS.

Sur une nouvelle forêt en Windows Server 2025, la signature LDAP est exigée par défaut et la liaison de canal est activée « quand elle est prise en charge ». Sur un domaine plus ancien mis à niveau, ces réglages ne changent pas tout seuls : on les impose par la GPO des contrôleurs (Options de sécurité > Contrôleur de domaine : exigences de signature du serveur LDAP → Exiger la signature), après avoir vérifié dans le journal Service d'annuaire (Directory Service) des contrôleurs qu'aucun client n'envoie encore de requêtes non signées : l'événement 2887 en donne le nombre chaque jour, et l'événement 2889 l'adresse de chaque client fautif une fois la journalisation de diagnostic « 16 LDAP Interface Events » réglée à 2. Pour la liaison de canal, ce sont les événements 3074 et 3075 qui signalent les clients non conformes. Le cours Authentification rappelle pourquoi toute application qui interroge l'annuaire doit passer par LDAPS.

RC4 et DES dans Kerberos

RC4 rend un ticket Kerberos cassable hors ligne (chapitre 2) et facilite le Kerberoasting ; DES est encore plus faible. Microsoft a retiré RC4 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 une clé de registre a disparu (changements liés à la CVE-2026-20833). Avant de couper RC4 complètement, on repère ce qui l'exige encore :

• les événements 201 à 209 du journal Système des contrôleurs (source KDCSVC) signalent les comptes et clients qui demandent ou n'acceptent que RC4 ;
• l'attribut msDS-SupportedEncryptionTypes de chaque compte dit quels chiffrements il accepte ;
• les applications et équipements anciens (NAS, imprimantes, logiciels Java mal configurés) sont les coupables habituels.

# Comptes qui autorisent encore DES ou RC4 (bits 0x1, 0x2 et 0x4 de msDS-SupportedEncryptionTypes)
Get-ADObject -LDAPFilter '(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.804:=7)' `
    -Properties msDS-SupportedEncryptionTypes, samAccountName |
    Select-Object samAccountName, msDS-SupportedEncryptionTypes

Le filtre utilise la règle de comparaison LDAP « OU bit à bit » (1.2.840.113556.1.4.804) : il retient les comptes dont l'attribut a au moins un des bits de la valeur 7 (DES-CBC-CRC, DES-CBC-MD5, RC4). Les comptes où l'attribut est vide n'apparaissent pas : depuis avril 2026, ils reçoivent de l'AES par défaut.

On corrige chaque cas (mettre à jour l'équipement, régler le compte en AES), puis on retire RC4 de la liste des chiffrements autorisés du domaine.

Fermer les autres portes

Appliquer une baseline plutôt que régler à la main

Régler tous ces points un par un est long et source d'erreurs. Microsoft fournit des baselines de sécurité : des ensembles de GPO testés, à importer et à lier. Pour Windows Server 2025, on peut :

• importer les GPO de la baseline livrée avec le Security Compliance Toolkit, les adapter, puis les lier aux OU (des contrôleurs, des serveurs, des postes), après test ;
• ou, directement sur un serveur, appliquer la baseline avec OSConfig : Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/DomainController -Default pour un contrôleur, et le scénario correspondant pour un serveur membre.

L'ANSSI complète ces baselines par ses recommandations (document de 2023 sur l'administration sécurisée) et ses points de contrôle (chapitre 4). On ne prend jamais une baseline telle quelle en production : on la teste, car certains réglages stricts cassent des usages légitimes.

Exercices