Signature SMB et liaison de canal LDAP ── boucler « l'autre moitié » des contre-mesures NTLM en pratique

« Nous avons commencé l’audit de NTLM. Nous corrigeons aussi les connexions par adresse IP en dur. Alors, en attendant d’avoir éliminé toutes les dépendances, comment se protéger contre les attaques par relais ? » — après la publication de notre précédent article « L’arrêt de NTLM va-t-il bloquer les applications métier ? », c’est la question que nous avons reçue le plus souvent.

La réponse, ce sont les sujets de cet article : la signature SMB et la signature LDAP / liaison de canal LDAP. Ni l’une ni l’autre n’est une mesure visant à « arrêter NTLM » : ce sont des défenses pour « empêcher, tant que NTLM subsiste, qu’une authentification volée puisse être relayée (attaque par relais) ». Et côté signature SMB, la valeur par défaut a réellement changé avec Windows 11 24H2 / Windows Server 2025 : elle arrive avec la mise à jour de l’OS, même sans intervention de votre part. De l’autre côté, la signature LDAP et la liaison de canal n’ont pas vu leur valeur par défaut changer : elles restent laxistes tant que l’administrateur ne les resserre pas lui-même. Autrement dit, pour SMB la question est « anticiper, ou subir un incident au moment de la mise à jour de l’OS », tandis que pour LDAP la question est « quand décider soi-même de resserrer ».

Cet article est le troisième volet de notre série sur NTLM. La procédure d’audit de NTLM est traitée dans le premier volet, et le fonctionnement du protocole dans le deuxième volet.

1. La conclusion, d’abord

• La signature SMB appose une signature de détection d’altération sur tous les messages SMB. La signature intègre un hachage du message entier ainsi que l’identité de l’émetteur et du destinataire, ce qui constitue une protection contre les attaques par relais et par usurpation.¹
• La valeur par défaut a déjà changé. Windows 11 version 24H2 Enterprise, Pro et Education rend désormais la signature obligatoire à la fois en émission et en réception, tandis que Windows Server 2025 la rend obligatoire uniquement en émission (l’édition Home n’est concernée dans aucun des deux cas).²
• Rendre la signature obligatoire va de pair avec la désactivation de l’accès invité. Les NAS qui ne prennent pas en charge la signature, ou les équipements reposant sur une connexion invité, tombent en erreur au moment de la mise à jour de l’OS. Le code d’erreur est 0xc000a000 (STATUS_INVALID_SIGNATURE), ou un message de blocage de l’accès invité (section 4.3).²
• La signature LDAP permet au contrôleur de domaine de refuser les « liaisons SASL sans exigence de signature » et les « liaisons simples en texte clair ». Le trafic LDAP non signé est vulnérable aux attaques par rejeu et à l’homme du milieu.³
• La liaison de canal LDAP relie l’authentification Windows (liaison SASL) effectuée sur LDAPS (SSL/TLS) au canal TLS lui-même. La valeur utilisée pour ce lien s’appelle le jeton de liaison de canal (CBT). Les liaisons simples, qui ne possèdent pas de CBT, ne sont pas concernées par cette vérification (chapitre 6). Le contrôle se fait via la valeur de registre LdapEnforceChannelBinding (0/1/2) ou par stratégie de groupe.⁴
• Les deux se déploient en trois étapes : lire les événements d’audit → corriger les sources → basculer en mode obligatoire. Pour la signature LDAP, les événements 2887 et 2889 permettent d’identifier les sources ; pour la liaison de canal, les événements 3039, 3040 ainsi que les événements d’audit 3074 et 3075 (chapitres 5 et 6).³⁴
• Point important : ces mises à jour ne modifient pas les valeurs par défaut d’elles-mêmes. Microsoft précise explicitement, pour l’ensemble des mises à jour LDAP publiées depuis mars 2020, que « les stratégies par défaut de la signature LDAP et de la liaison de canal LDAP ne changent pas ». Les resserrer reste le travail de l’administrateur.⁴

2. Pourquoi signer ── « l’autre moitié » de l’attaque par relais

Comme nous l’avons écrit dans le deuxième volet de cette série, la faiblesse fondamentale de NTLM est l’absence d’authentification mutuelle. Le client ne peut pas vérifier l’identité du serveur, si bien qu’un attaquant peut se faire passer pour un « vrai serveur » afin de faire authentifier le client, puis relayer telle quelle la réponse d’authentification reçue vers le véritable serveur. C’est l’attaque par relais, et Microsoft indique lui-même explicitement que l’authentification NTLM et NTLMv2 est vulnérable au relais SMB et aux attaques de l’homme du milieu.⁵

Arrêter complètement NTLM rendrait cette attaque impossible, mais comme nous l’avons vu dans le premier volet, le recensement des dépendances et leur correction prennent plusieurs mois. La signature est la défense qui couvre cet intervalle.

flowchart LR
    CL["Client"]
    AT["Attaquant<br/>(faux serveur)"]
    SV["Véritable serveur"]

    CL -->|"① Réponse d'authentification"| AT
    AT -->|"② Relai tel quel"| SV
    SV -.->|"③ Si la signature est obligatoire :<br/>l'attaquant, dépourvu de clé de session,<br/>ne peut pas produire de signature valide et échoue"| AT

Figure 1 : relation entre l’attaque par relais et la signature SMB

Le point clé est que la clé de signature (clé de session) n’est détenue, à l’issue de l’authentification, que par le client et le véritable serveur. Un attaquant qui s’est contenté de relayer la réponse d’authentification ne possède pas cette clé de session ; dans un environnement où la signature est obligatoire, il ne peut donc plus falsifier les messages suivants. La signature SMB bloque le relais vers SMB, tandis que la signature LDAP et la liaison de canal bloquent le relais vers le LDAP/LDAPS du contrôleur de domaine.

Une autre remarque pratique : l’efficacité de la signature n’est pas indépendante du choix du protocole d’authentification. Comme la clé de session dérive du mot de passe, s’authentifier en NTLMv2 plutôt qu’en Kerberos affaiblit la clé sur laquelle repose la signature. Microsoft cite d’ailleurs l’usage de Kerberos et le fait de ne pas se connecter à un partage via une adresse IP ou un CNAME comme conditions pour maximiser l’efficacité de la signature SMB.¹ En effet, se connecter via une adresse IP ou un alias sans SPN correspondant enregistré fait basculer l’authentification vers NTLM plutôt que Kerberos (l’enregistrement de SPN, si vous souhaitez continuer à utiliser un alias, est traité dans le premier volet). Autrement dit, réduire la dépendance à NTLM et rendre la signature obligatoire ne sont pas deux mesures distinctes, mais les deux faces d’une même démarche.

3. Signature SMB ── mécanisme, et une valeur par défaut déjà changée

3.1. Le mécanisme en une minute

La signature SMB appose, à l’aide de la clé de session et de la suite cryptographique, une signature sur chaque message qui transite sur la connexion. La signature intègre, dans l’en-tête SMB, un hachage du message entier : toute altération en cours de route fait échouer la correspondance du hachage. Le hachage inclut aussi l’identité de l’émetteur et du destinataire, ce qui permet également de détecter l’usurpation.¹

L’algorithme s’est renforcé de génération en génération. SMB1 utilisait MD5 ; SMB 2.02 est passé à HMAC-SHA-256, SMB 3.0 à AES-CMAC, et Windows Server 2022 ainsi que Windows 11 ont introduit une accélération de la signature par AES-128-GMAC.¹ Si votre souvenir « signature = lenteur » date de l’époque de SMB1, cela vaut la peine de l’oublier et de remesurer.

Le paramétrage se raisonne non pas en termes de « activé/désactivé », mais de « obligatoire (Require) ou non ». À partir de SMB 2.x, le paramètre EnableSecuritySignature est ignoré ; seul RequireSecuritySignature a un effet. Et dès que l’une des deux parties, client ou serveur, rend la signature obligatoire, la connexion est signée. La signature n’est absente que si aucune des deux parties ne l’a rendue obligatoire.¹

3.2. Tableau de décision sur les valeurs par défaut

Il n’est pas nécessaire de lire ce tableau en entier. Commencez par vérifier l’OS et l’édition de vos postes et serveurs, et ne lisez que la ligne qui vous concerne. L’édition et la version se consultent dans « Paramètres > Système > Informations système » (« Édition » affiche Pro/Home/Enterprise/Education etc., « Version » affiche 24H2 etc.).

Les trois premières lignes sont les valeurs par défaut explicitement documentées par Microsoft.² La dernière ligne correspond à un comportement de longue date : le contrôleur de domaine exige la signature SMB de tous ceux qui s’y connectent. La distribution des stratégies de groupe et des scripts de connexion a toujours fonctionné en présupposant la signature.¹

Seule l’édition Home échappe à ce changement de valeur par défaut. Comme ni l’émission ni la réception n’y deviennent obligatoires, la mise à jour vers 24H2 ne provoque pas d’erreur de connexion liée à la signature obligatoire sur un poste Home (cela n’est pas garanti pour des versions futures, mais du moins, au moment de 24H2, ces postes ne font pas partie de « l’échéance »).² Autrement dit, à version 24H2 égale, le comportement diffère selon l’édition. Lorsque vous instruisez un signalement du type « depuis la mise à jour, impossible de se connecter au partage », vérifiez l’édition en tout premier lieu, pas seulement la version.

L’implication pratique de ce tableau est la suivante : la mise à jour vers Windows 11 24H2 (Enterprise, Pro, Education) rend obligatoire la signature de toutes les connexions SMB sortant de ce PC (Home n’est pas concerné). Si votre serveur de fichiers interne est sous Windows, rien ne se passe (Windows prend en charge la signature dans toutes ses versions). Les incidents surviennent face à des équipements tiers qui ne prennent pas en charge la signature, ou qui l’ont désactivée : anciens NAS, paramètres d’enregistrement de numérisation de photocopieurs multifonctions, Samba sur Linux embarqué, etc.

4. Faire évoluer la signature SMB vers l’obligatoire

4.1. Vérifier l’état actuel

# Exigence de signature côté client (émission)
Get-SmbClientConfiguration | FL RequireSecuritySignature

# Exigence de signature côté serveur (réception)
Get-SmbServerConfiguration | FL RequireSecuritySignature

True signifie obligatoire, False signifie non obligatoire.² Si vous gérez cela par stratégie de groupe, l’emplacement est Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité, avec « Client réseau Microsoft : toujours signer numériquement les communications » (client) et « Serveur réseau Microsoft : toujours signer numériquement les communications » (serveur). Le « toujours (always) » dans le nom de la stratégie signifie « obligatoire ».¹

4.2. Recenser d’abord « les correspondants qui ne peuvent pas signer » (audit)

À partir de Windows 11 version 24H2, vous pouvez activer un audit qui détecte les clients et serveurs tiers ne prenant pas en charge la signature ou le chiffrement.¹

# Côté serveur : détecter les clients qui ne prennent pas en charge la signature
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# Côté client : détecter les serveurs qui ne prennent pas en charge la signature
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

Le même mécanisme propose aussi un audit qui détecte les correspondants ne prenant pas en charge le chiffrement (-AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption),¹ mais il s’agit d’une préparation en vue d’une future obligation du chiffrement SMB, une trajectoire distincte de celle de la signature. Il n’est pas rare qu’un équipement prenne en charge la signature mais pas le chiffrement : ne mélangez pas les événements d’audit du chiffrement dans votre évaluation d’achèvement de la signature.

Voici où sont enregistrés les événements.¹

Voici les trois étapes pour consulter ces événements.

1. Ouvrez l’Observateur d’événements avec eventvwr.msc, puis dans l’arborescence de gauche, ouvrez Observateur d’événements > Journaux des applications et des services > Microsoft > Windows > SMBClient > Audit (pour le côté serveur, la même hiérarchie sous SMBServer > Audit).
2. Dans le volet de droite, choisissez « Filtrer le journal actuel » et saisissez 31998,31999 dans le champ « Tous les ID d’événement » (côté serveur : 3021,3022).
3. En ouvrant les événements restants, vous trouverez les informations sur les correspondants qui ne prenaient pas en charge la signature. Reportez-les dans votre inventaire d’équipements.

Pour les récupérer en masse avec PowerShell :

# Côté client : événements d'audit détectant des serveurs ne prenant pas en charge la signature
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# Côté serveur : événements d'audit détectant des clients ne prenant pas en charge la signature
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

Si aucun événement n’a encore été enregistré juste après l’activation de l’audit, Get-WinEvent renvoie une erreur signalant l’absence d’événement correspondant (c’est pour cette raison que -ErrorAction SilentlyContinue est ajouté ci-dessus). La manière d’affiner ces filtres est détaillée dans « Explorer les journaux d’événements en pratique avec Get-WinEvent ».

Par stratégie de groupe, ces réglages correspondent à « Audit client does not support signing » et équivalents, sous Lanman Server / Lanman Workstation, dans Configuration ordinateur\Modèles d'administration\Réseau.¹ La logique de durée d’audit décrite dans le premier volet (faire tourner l’audit jusqu’à ce qu’un cycle complet d’activité ait été couvert) s’applique ici de la même façon.

4.3. Connaître les scénarios d’incident

Se connecter, dans un environnement où la signature est obligatoire, à un correspondant incapable de signer produit l’erreur suivante.²

0xc000a000
STATUS_INVALID_SIGNATURE
Signature chiffrée non valide.

Un autre point facile à manquer est l’accès invité. Rendre la signature obligatoire entraîne aussi la désactivation de l’accès invité. Se connecter à un NAS configuré pour un accès sans authentification (invité) produit une erreur du type suivant.²

L'accès invité non authentifié à ce dossier partagé est bloqué
par la stratégie de sécurité de votre organisation.

L’ordre de priorité des correctifs est clair. La première option consiste à activer la signature SMB côté équipement et à faire authentifier avec des identifiants plutôt qu’en tant qu’invité. Définir Set-SmbClientConfiguration -RequireSecuritySignature $false côté client permet d’éviter l’erreur de signature (0xc000a000), mais le blocage de l’accès invité provient d’un autre paramètre client (l’interdiction de la connexion invité non sécurisée), distinct de la signature, et assouplir uniquement la signature ne le résout pas. Microsoft ne recommande ni de désactiver la signature comme contournement pour des équipements tiers, ni d’utiliser un compte invité avec la signature.² Si vous devez assouplir malgré tout, traitez cela comme « une exception à durée limitée, jusqu’au remplacement de cet équipement ».

4.4. Ordre de déploiement

À mesure que le parc de postes en 24H2 ou au-delà augmente, « le côté client obligatoire par défaut » se généralise progressivement, si bien que l’échéance effective est en réalité fixée par le plan de mise à jour de l’OS. Les organisations en cours de migration vers Windows 11 24H2 ou au-delà dans le cadre de la fin de support de Windows 10 devraient inclure cette vérification comme un prérequis de leur migration (voir « Les options à la fin du support de Windows 10 »).

5. Signature LDAP ── protéger le chemin vers le contrôleur de domaine

Dans ce chapitre et le suivant, le type de « liaison » est au cœur du sujet ; commençons donc par clarifier deux termes.

Autrement dit, « rendre la signature LDAP obligatoire » signifie exiger la signature pour les liaisons SASL et refuser les liaisons simples en connexion non chiffrée.

Après SMB, voici LDAP. Le trafic LDAP non signé vers un contrôleur de domaine (et AD LDS) est vulnérable aux attaques par rejeu et à l’homme du milieu. Si un attaquant intercepte et modifie des paquets avant de les transférer au serveur, celui-ci risque de prendre des décisions fondées sur une requête falsifiée.³

Rendre la signature LDAP obligatoire revient à faire refuser par le serveur d’annuaire les deux types de liaisons suivants.³

1. Les liaisons SASL n’exigeant pas de signature (intégrité) (le SASL inclut Negotiate, Kerberos, NTLM, Digest)
2. Les liaisons simples effectuées sur une connexion en texte clair (non SSL/TLS)

5.1. Tableau récapitulatif des ID d’événement (signature LDAP et liaison de canal)

Récapitulons d’abord les ID d’événements qui apparaissent dans ce chapitre et le chapitre 6. Tous sont enregistrés dans le journal « Directory Service » du contrôleur de domaine (Observateur d’événements > Journaux des applications et des services > Directory Service). Ce tableau permet de bâtir directement la conception de l’audit.

L’usage est simple. Pour voir « combien il en reste encore », consultez les événements d’agrégation (2887, 3040) ; pour voir « d’où cela vient », consultez les événements individuels (2889, 3039, 3074, 3075). Tant que le nombre n’atteint pas zéro, ne passez pas au mode obligatoire. Nous détaillons ensuite la signature LDAP en section 5.2 et la liaison de canal au chapitre 6.

5.2. Auditer d’abord ── événements 2886/2887/2889

Le journal Directory Service du contrôleur de domaine offre déjà des indices dès le départ. Parmi les événements du tableau de la section 5.1 liés à la signature LDAP, on trouve 2886, 2887, 2888 et 2889 ; parmi ceux-ci, 2887 indique « combien de liaisons non signées restent encore », et 2889 indique « d’où elles viennent » (2888 est l’agrégat après configuration du rejet).³

Seul 2889 n’apparaît pas par défaut. Il commence à être enregistré une fois le paramètre de diagnostic « 16 LDAP Interface Events » élevé à 2 (Basic).³ La démarche consiste d’abord à observer l’agrégat de 2887 pour savoir « combien de liaisons non signées existent au total », puis, si ce nombre n’est pas nul, à activer 2889 pour identifier les sources. Attention : 2889 n’est pas un agrégat mais s’enregistre à chaque occurrence de la liaison concernée ; dans un environnement où des liaisons héritées subsistent à haute fréquence, cela peut rapidement saturer le journal Directory Service. Une fois les sources identifiées, remettez le paramètre de diagnostic à son niveau initial (0 par défaut). Si vous souhaitez le laisser actif en continu, assurez-vous d’abord de la redirection et de la rétention des journaux.

Les sources typiques sont les applications métier reliées à LDAP (fédération d’authentification, intégration RH), la recherche dans le carnet d’adresses LDAP des multifonctions, et l’authentification LDAP des équipements réseau. Les paramètres « serveur LDAP » des multifonctions et autres équipements utilisent souvent une liaison simple en texte clair : c’est le premier suspect à examiner. La correction consiste à faire basculer la configuration de l’équipement ou de l’application vers LDAPS (port 636) ou vers une liaison SASL signée.

5.3. Passer en mode obligatoire

Une fois les sources corrigées, appliquez l’obligation via stratégie de groupe.³

• Côté contrôleur de domaine : dans la Default Domain Controller Policy, sous Options de sécurité, réglez « Contrôleur de domaine : Exigences de signature pour serveur LDAP » sur « Exiger la signature »
• Côté client : réglez « Sécurité réseau : Exigences de signature pour client LDAP » sur « Exiger la signature »

La vérification peut se faire avec ldp.exe. Connectez-vous au port 389 et tentez une liaison simple : si la configuration est effective, vous obtenez l’erreur suivante.³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. Liaison de canal LDAP ── la protection côté LDAPS

« Nous sommes en LDAPS, donc tout va bien » — c’est justement la brèche que colmate la liaison de canal. LDAPS chiffre la communication, mais cela seul ne suffit pas à empêcher une forme de relais consistant à « faire authentifier le client, puis relayer ces informations d’authentification vers une autre connexion TLS contrôlée par l’attaquant ». Le jeton de liaison de canal (CBT) rend ce relais vers un autre canal détectable, en liant l’authentification au canal TLS lui-même.

Précisément, la cible concernée est une connexion effectuant une authentification Windows (liaison SASL), NTLM ou Kerberos par exemple, sur LDAPS. Les liaisons simples, ne possédant pas de CBT par nature, ne sont pas concernées par cette vérification. Ce qui protège une liaison simple sur LDAPS est le chiffrement TLS et la gestion des identifiants eux-mêmes ; même en réglage Always, un client en liaison simple n’apparaîtra jamais dans les événements d’audit du CBT.

Le contrôle se fait via la valeur de registre du contrôleur de domaine, ou la stratégie de groupe correspondante.⁴

Voici les événements utilisés pour l’audit (le contenu détaillé, côté liaison de canal, du tableau récapitulatif de la section 5.1). La mise à jour du 10 mars 2020 a ajouté les événements liés à la liaison de canal, et les mises à jour à partir de 2023 ont enrichi les événements d’audit.⁴

La démarche est la même que pour la signature LDAP, et les recommandations de Microsoft vont dans le même sens : « surveiller, dans le journal Directory Service de tous les contrôleurs de domaine, l’événement 2889 pour les échecs de signature, l’événement 3039 pour les échecs de liaison de canal, ainsi que les événements d’audit 3074 et 3075, identifier les équipements problématiques, vérifier auprès du fournisseur, confirmer la prise en charge, puis passer en mode obligatoire ».⁴

Un point mérite d’être souligné : Microsoft n’a pas modifié les valeurs par défaut avec ces mises à jour. Il est explicitement indiqué que la mise à jour du 10 mars 2020, ainsi que les mises à jour ultérieures, ne changent pas les stratégies par défaut de la signature LDAP et de la liaison de canal LDAP.⁴ Contrairement à la signature SMB (dont la valeur par défaut a changé avec 24H2), le côté LDAP reste laxiste tant que l’administrateur ne le resserre pas lui-même. Vu autrement, cela signifie que vous pouvez avancer de manière planifiée tant que vous choisissez vous-même le moment de resserrer.

7. Corriger les applications métier et les équipements (tableau de décision)

Organisons par cause les sources identifiées lors de l’audit.

Pour une application .NET développée en interne manipulant LDAP, la première chose à vérifier est « la liaison simple est-elle envoyée en texte clair ? ».

// Mauvais exemple : liaison simple en texte clair vers le port 389. Sera rejetée si la signature LDAP est rendue obligatoire
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

// Bon exemple 1 : exiger Negotiate + signature/chiffrement (Kerberos est choisi si le SPN et la résolution de noms sont en place)
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind();  // Authentification avec le compte d'exécution

// Bon exemple 2 : si vous utilisez une liaison simple, passez impérativement par LDAPS
var id = new LdapDirectoryIdentifier("dc01.corp.example.com", 636);
var conn2 = new LdapConnection(id);
conn2.SessionOptions.SecureSocketLayer = true;
conn2.AuthType = AuthType.Basic;
conn2.Bind(new NetworkCredential(user, password));

Le bon exemple 1, avec Negotiate, privilégie Kerberos mais ne l’impose pas. Si la destination est une adresse IP, ou si le SPN n’est pas enregistré ou est dupliqué, le basculement vers NTLM se fait silencieusement (l’exigence de signature/chiffrement reste néanmoins active dans ce cas). Pour vérifier avec certitude que l’authentification se fait bien en Kerberos, le plus sûr est de confirmer avec klist qu’un ticket a bien été obtenu pour le service concerné. Si vous avez activé l’audit NTLM (auditer tout le trafic NTLM sortant) décrit dans le premier volet, l’absence de l’événement 8001 constitue également un indice indirect — mais attention, tant que la stratégie d’audit reste désactivée, « l’absence de 8001 » n’a aucune signification. Notez que le bon exemple 2, en liaison simple, est chiffré par TLS, mais comme indiqué au chapitre 6, c’est bien le côté authentification Windows qui fait l’objet de la vérification du CBT. Dans un environnement de domaine, privilégiez le bon exemple 1 lorsque le choix est possible. Via DirectoryEntry (ADSI), le plus sûr est de spécifier explicitement AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing. Le principe énoncé dans le premier volet de la série NTLM (écrire la destination en FQDN plutôt qu’en adresse IP) reste également déterminant ici, comme condition préalable à l’aboutissement d’une liaison SASL en Kerberos.

8. Conclusion

• La signature SMB et la signature LDAP / liaison de canal sont des défenses qui empêchent l’attaque par relais tant que la dépendance à NTLM n’est pas totalement éliminée, mais ce sont aussi des renforcements permanents à conserver après l’abandon de NTLM (la détection d’altération de la signature et la liaison de canal restent efficaces même pour des sessions authentifiées par Kerberos). Faites-les avancer comme les deux faces d’une même démarche que la réduction de NTLM.¹⁵
• La valeur par défaut de la signature SMB a déjà changé. Windows 11 24H2 (Enterprise/Pro/Education) la rend obligatoire à l’émission comme à la réception, Windows Server 2025 uniquement à l’émission. Le plan de mise à jour de l’OS devient de fait l’échéance.²
• Les scénarios d’incident sont bien identifiés : l’erreur 0xc000a000 pour les équipements non compatibles avec la signature, et le blocage de l’accès invité. Les fonctions d’audit de 24H2 et au-delà permettent de les recenser en amont.²¹
• Pour LDAP, identifiez les sources via les événements 2887 et 2889 (signature), 3039, 3040, 3074 et 3075 (liaison de canal), corrigez, puis rendez le tout obligatoire.³⁴
• La valeur par défaut côté LDAP ne change pas avec les mises à jour. Elle reste laxiste tant que l’administrateur ne la resserre pas. Avancez de manière planifiée pendant que vous en avez encore le temps.⁴
• Pour vos applications internes, éliminer « la liaison simple en texte clair » et « les adresses IP en dur » règle la grande majorité des cas.

Articles connexes

• L’arrêt de NTLM va-t-il bloquer les applications métier ? ── Comment collecter les journaux d’audit et l’ordre pour éliminer les dépendances
• NTLM et Kerberos expliqués en images ── pourquoi l’authentification « retombe » sur NTLM
• Les pièges des lecteurs réseau et des chemins UNC ── manipuler des serveurs de fichiers (dossiers partagés) dans les applications métier
• Explorer les journaux d’événements en pratique avec Get-WinEvent ── la rapidité du filtrage détermine le temps d’investigation
• La réalité après la fin de support de Windows 10 ── un tableau de décision entre ESU, LTSC et remplacement
• Liste de contrôle minimale de sécurité pour les applications Windows

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge la modification des applications métier liée à l’obligation de la signature SMB et de la signature LDAP, ainsi que l’investigation des incidents de connexion autour de l’authentification et du partage de fichiers.

• Développement d’applications Windows
• Investigation de bugs et analyse de causes
• Valorisation des actifs existants et accompagnement de migration
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Si je rends la signature SMB obligatoire, le serveur de fichiers ne va-t-il pas ralentir ?

Le coût de calcul de la signature n'est pas nul, mais l'algorithme s'est amélioré de génération en génération. Face au MD5 de SMB1, SMB 2.02 utilise HMAC-SHA-256, SMB 3.0 utilise AES-CMAC, et Windows Server 2022 ainsi que Windows 11 ont introduit une accélération de la signature par AES-128-GMAC. De plus, les contrôleurs de domaine exigent depuis longtemps la signature SMB de tous ceux qui se connectent à SYSVOL et NETLOGON, et la distribution des stratégies de groupe fonctionne depuis toujours en supposant la signature. Avant d'écarter l'idée pour des raisons de performance, nous recommandons de rendre la signature obligatoire sur un poste pilote et de mesurer réellement l'impact. Un écart perceptible ne se produit que dans des usages particuliers, comme le transfert continu de fichiers volumineux.

Depuis le passage à Windows 11 24H2, je n'arrive plus à me connecter à mon NAS. Est-ce la signature SMB ?

C'est typiquement la cause. Windows 11 version 24H2 Enterprise, Pro et Education rend désormais la signature SMB obligatoire par défaut à la fois en émission et en réception. Se connecter à un NAS tiers qui ne prend pas en charge la signature (ou qui l'a désactivée) échoue alors avec l'erreur 0xc000a000 (STATUS_INVALID_SIGNATURE). Par ailleurs, comme rendre la signature obligatoire désactive aussi l'accès invité, un NAS configuré pour un usage sans authentification affichera une erreur du type « l'accès invité non authentifié est bloqué par la stratégie de sécurité de votre organisation ». La première solution consiste à activer la signature SMB côté NAS et à se connecter avec des identifiants plutôt qu'en tant qu'invité. Il existe un contournement côté client consistant à désactiver l'exigence de signature, mais cela ne résout que le volet « erreur de signature ». Le blocage de la connexion invité provient d'un autre paramètre client (l'interdiction de la connexion invité non sécurisée), distinct de la signature, et reste en échec tant que ce paramètre n'est pas assoupli également. Microsoft ne recommande ni de désactiver la signature ni de fonctionner en mode invité.

Quelle est la différence entre la signature LDAP et LDAPS (LDAP sur SSL/TLS) ?

Ce sont deux choses différentes. La signature LDAP est un mécanisme qui exige une vérification d'intégrité (signature) sur les liaisons SASL (Negotiate, Kerberos, NTLM, Digest) effectuées sur une connexion LDAP au port 389 ; elle ne chiffre pas la communication. LDAPS est un mécanisme qui chiffre l'ensemble de la connexion avec SSL/TLS. Et la liaison de canal LDAP est une protection supplémentaire, au-dessus de LDAPS, qui relie l'authentification au canal TLS afin d'empêcher les attaques consistant à « relayer uniquement les informations d'authentification vers une autre connexion TLS ». Pour protéger un contrôleur de domaine, il faut penser en trois volets : abandonner les liaisons simples en texte clair, exiger la signature pour les liaisons SASL, et exiger la vérification du jeton de liaison de canal pour l'authentification Windows (liaison SASL) sur LDAPS. Notez que les liaisons simples sans CBT ne sont pas concernées par la vérification de liaison de canal : ce qui protège une liaison simple sur LDAPS est le chiffrement TLS lui-même.

Dans quel ordre faut-il procéder ?

L'ordre audit → correction → obligation est le même que pour la restriction de NTLM. Pour SMB, commencez par activer, à partir de Windows 11 24H2, l'audit qui détecte les correspondants ne prenant pas en charge la signature, afin de recenser les équipements incapables de signer. Pour LDAP, consultez le journal Directory Service du contrôleur de domaine pour l'événement 2887 (l'agrégat quotidien des liaisons non signées) ; s'il y a des occurrences, passez le paramètre de diagnostic « 16 LDAP Interface Events » à 2 pour identifier les clients via l'événement 2889. Pour la liaison de canal, procédez de la même façon avec les événements 3039 et 3040, ainsi qu'avec les événements d'audit 3074 et 3075 ajoutés par les mises à jour de 2023. Une fois toutes les sources problématiques corrigées, basculez la signature SMB en obligatoire, la signature LDAP en obligatoire, puis la liaison de canal sur Always. Le seul principe à respecter est de ne jamais passer en mode obligatoire précipitamment.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.