Retirer SMBv1 d'un contrôleur de domaine sans rien casser

Le contexte

L'annuaire Active Directory de l'entreprise, une PME d'une vingtaine de personnes, n'avait jamais été audité. Au premier scan PingCastle de son audit de sécurité, trois des quatre catégories étaient à 100/100, le pire score possible. La règle la plus lourde, à 100 points : SMBv1 actif sur le contrôleur de domaine.

Deux contraintes cadraient le travail : aucun environnement de test, chaque commande passait sur les contrôleurs de production ; et aucune coupure non annoncée.

Le risque, dans les deux sens

SMBv1 est la première version du protocole de partage de fichiers de Windows. C'est elle que vise EternalBlue, l'exploit de la faille corrigée par le bulletin MS17-010, divulgué en 2017 et utilisé par les rançongiciels WannaCry et NotPetya : il permet d'exécuter du code à distance, sans authentification. Sur un contrôleur de domaine, cela revient à donner la main sur tout l'annuaire. Microsoft déconseille ce protocole et ne l'installe plus par défaut sur les versions récentes de Windows.

Le risque inverse existait aussi. Couper SMBv1 sur un contrôleur peut bloquer un vieil équipement qui en dépend encore, par exemple pour lire les stratégies de groupe ou les scripts de connexion partagés par le contrôleur. Sans environnement de test, il fallait le découvrir en observant la production.

Écouter avant de couper

Windows sait journaliser les accès SMBv1 sans les bloquer. Une fois l'audit activé, chaque connexion d'un client en SMBv1 laisse un événement 3000 dans le journal Microsoft-Windows-SMBServer/Audit, avec l'adresse du client. On obtient ainsi la liste des équipements à mettre à jour avant de couper.

J'ai laissé cette écoute tourner cinq jours. Résultat : aucun accès SMBv1. Le NAS utilisait déjà une version plus récente du protocole.

Couper en deux temps

J'ai d'abord désactivé SMBv1 dans la configuration du serveur SMB, puis désinstallé le composant. La désactivation empêche le serveur d'accepter ce protocole, et la même commande permet de revenir en arrière. La désinstallation retire le code du système : une faille dans un composant absent ne peut plus être exploitée. Elle ne prend effet qu'au redémarrage.

PowerShell · retrait de SMBv1

# 1. Écouter : chaque accès SMBv1 laisse un événement 3000
Set-SmbServerConfiguration -AuditSmb1Access $true -Force
Get-WinEvent -LogName "Microsoft-Windows-SMBServer/Audit" | Where-Object Id -eq 3000

# 2. Aucun accès en 5 jours : désactivation, puis désinstallation
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

# 3. Après le redémarrage : forcer la réplication et lire le résultat
repadmin /syncall /AdeP

Redémarrer pendant que le second contrôleur authentifie

Le domaine compte deux contrôleurs. Les postes trouvent un contrôleur grâce au DNS ; si l'un ne répond pas, ils s'adressent à l'autre. Les deux contrôleurs étaient aussi les serveurs DNS du réseau.

Le contrôleur principal est un serveur physique : son redémarrage a pris environ 25 minutes, le temps des tests matériels au démarrage et de l'initialisation du RAID. Pendant ce temps, le second contrôleur a assuré l'authentification.

Vérifier que tout est revenu

Un contrôleur qui redémarre sans erreur visible peut quand même mal fonctionner. Après le redémarrage, j'ai contrôlé deux points :

• Les services de l'annuaire : base Active Directory (NTDS), DNS, Netlogon et KDC, le service qui délivre les tickets Kerberos. Tous étaient démarrés.
• La réplication : pendant le redémarrage, les changements de mots de passe ou de comptes n'arrivaient qu'au second contrôleur, et les deux doivent ensuite se remettre d'accord. L'annuaire se réplique par partitions : schéma, configuration, domaine, zones DNS. repadmin /syncall /AdeP force la synchronisation de toutes les partitions avec les partenaires de réplication, dans tous les sites, et affiche chaque erreur. Elle a réussi sur les cinq partitions.

Au dernier scan PingCastle, en août 2026, SMBv1 était bien désinstallé du contrôleur, et l'opération n'avait causé aucune coupure imprévue.

Ce que j'en retiens

• Écouter avant de couper. Quand un protocole ancien peut encore servir, son journal d'audit dit qui l'utilise. Cinq jours d'écoute ont remplacé une supposition par une mesure.
• Se servir de la redondance pour intervenir. Deux contrôleurs permettent d'en redémarrer un pendant que l'autre authentifie. Un serveur physique peut mettre 25 minutes à revenir : c'est à prévoir dans le créneau d'intervention.
• Vérifier après, pas seulement avant. Un contrôleur qui démarre n'est pas forcément un contrôleur qui réplique : services et réplication se contrôlent après chaque redémarrage.