Impossible de mapper un partage Samba depuis Windows Server 2025 : causes, solutions et bonnes pratiques

Depuis l’aperçu de Windows Server 2025, de nombreux administrateurs constatent l’échec systématique du montage de partages Samba ou NAS non signés. Cet article explique en détail le pourquoi et le comment résoudre durablement ce problème, tout en préservant la sécurité de votre infrastructure.

Sommaire

Impossibilité de mapper un partage Samba depuis Windows Server 2025

Problématique

Lors de la tentative de connexion à un partage réseau (net use, Explorateur, GPO d’attribution de lecteurs, etc.), Windows Server 2025 affiche le message :

The mapped network drive could not be created because the following error has occurred:
An extended error has occurred.

Dans les journaux SMB Client (Microsoft-Windows-SMBClient/Operational) on observe :

SMB signing negotiation failed | STATUS_ACCESS_DENIED | RequireSecuritySignature=1

Le phénomène n’apparaît pas :

sur Windows 11 (23H2) ;
sur Windows Server 2022 (Patch Tuesday juin 2025 inclus) ;
quel que soit le mode d’accès : invité, NTLM, Kerberos, compte local ou domaine.

Cause identifiée : généralisation de la signature SMB obligatoire

Microsoft poursuit le durcissement initié avec Windows 11 22H2 : le paramètre RequireSecuritySignature est désormais positionné à True par défaut pour le service Microsoft Network Client. La stratégie équivalente est :

GPMC → Computer Configuration  
  → Windows Settings  
   → Security Settings  
    → Local Policies  
     → Security Options  
      → "Microsoft network client: Digitally sign communications (always)" = Enabled

Tout serveur SMB qui ne propose pas la signature (server signing = no ou disabled) est immédiatement rejeté lors de la phase de négociation protocolaire, avant même l’étape d’authentification. D’où l’erreur générique côté client.

Solutions et bonnes pratiques

Approche	Commandes / réglages	Impact sécurité	Scénarios adaptés
1. Désactiver la signature côté client (temporaire)	`PowerShell (admin) Set-SmbClientConfiguration -RequireSecuritySignature $false Ou GPO : "Microsoft network client: Digitally sign communications (always)" = Disabled`	Réduit la protection MITM ; expose aux attaques de relais SMB.	Lab, dépannage, maquettes isolées.
2. Activer la signature côté serveur (recommandé)	`# smb.conf (Samba ≥ 4.17) server signing = mandatory # (ou 'auto' avec authentification) # puis systemctl restart smbd`	Aligne la sécurité sur la norme attendue 2025+.	Serveurs Samba, TrueNAS, OpenMediaVault, Synology (DSM 7.2+), QNAP.
3. Contournements provisoires	Montage depuis un jump‑host Windows 11/Server 2022, puis `ROBOCOPY`/`DFS‑R`. Accès NFS/SSHFS si disponible. Mise à jour firmware NAS quand le patch dépend du constructeur.	Variables.	Lorsque le serveur ne peut pas être modifié immédiatement.

Étapes de validation après modification

Lancer gpupdate /force, ou recharger smbd, puis redémarrer la session.
Contrôler la configuration : Get-SmbClientConfiguration | Format-List RequireSecuritySignature
Tester le montage : net use Z: \\srv-samba\partage /user:guest ""
Dans l’Observateur d’événements, vérifier l’absence de STATUS_ACCESS_DENIED.

Comprendre la signature SMB : fonctionnement et bénéfices

La signature insère un HMAC‑SHA256 (ou SHA‑512 pour SMB 3.x) dans chaque paquet afin de garantir l’intégrité et l’authenticité des données. Contrairement au chiffrement (EncryptData = True), le payload demeure lisible mais toute altération est détectée. Les gains :

Protection contre le spoofing et le hijacking : un attaquant ne peut plus insérer ou modifier des paquets sans être détecté.
Contrôle de bout en bout même en mode invité : la clé de session est dérivée pendant le négociation, signature possible sans chiffrement.
Gestion simplifiée depuis Windows 11 23H2 : rapports de conformité Microsoft Defender for Endpoint listent les partages non signés.

Impact performance réel

Sur des CPU récents (AES‑NI/AVX2), la surcharge constatée dans les laboratoires Microsoft est inférieure à 2 % du débit SMB 3.1.1 (Kb/s). Les goulots d’étranglement IO ou réseau masquent le coût cryptographique. Sur un NAS ARMv7 2014, on mesure ~7 % de perte, compensable en activant le multicanal SMB si disponible.

Configurer la signature côté Samba/NAS en profondeur

Versions minimales recommandées

Samba 4.17 : adopte server signing = mandatory comme valeur par défaut lorsque guest ok = yes.
TrueNAS CORE 13.1‑U2 : option graphique SMB → Advanced → Enable SMB signing.
Synology DSM 7.2 : File Services → SMB → Advanced Settings → Maximum protocol SMB 3 → Enable SMB signing.

Paramètres clés de `smb.conf`

[global]
  server signing       = mandatory   # auto|mandatory|disabled
  server min protocol  = SMB2
  client ipc signing   = auto
  map to guest         = Bad User
  ntlm auth            = yes         # si authentification legacy

Astuce : pour appliquer rapidement le réglage à tous les partages, ajouter include = /etc/samba/common-signing.conf et gérer la directive dans un fichier unique.

Déboguer la négociation avec Wireshark

Filtrer : smb2.cmd == 0 (Negotiate Protocol).
Observer les champs : NegotiateContextList → SMB2_SIGNING_CAPABILITIES.
Si Required = 1 côté client et Enabled = 0 côté serveur, la session est abandonnée immédiatement.

Scénarios pratiques et scripts d’audit

Inventorier les partages non signés dans un domaine Active Directory

Import-Module ActiveDirectory
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} | Select-Object -Expand Name
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-SmbServerConfiguration | Select-Object @{n="Computer";e={$env:COMPUTERNAME}}, 
      EnableSecuritySignature, RequireSecuritySignature
} | Format-Table -AutoSize

Automatiser la correction via Ansible (extrait)

- name: Activer la signature SMB
  hosts: samba
  become: yes
  tasks:
    - ini_file:
        path: /etc/samba/smb.conf
        section: global
        option: server signing
        value: mandatory
    - service:
        name: smbd
        state: restarted

FAQ rapide

Puis‑je forcer la signature sur un partage précis seulement ?

Oui, depuis Samba 4.18, la directive vfs objects = catia streams_xattr accepte server signing au niveau share. Cependant, Windows Server 2025 négocie d’abord au niveau serveur ; il est plus simple de l’imposer globalement.
SMB environnement mixte : comment éviter les alertes Defender ?

Activez l’option RequireSecuritySignature sur tous les clients Windows 10 22H2+ via une GPO et surveillez les serveurs non conformes dans le tableau de bord Secure Score.
Quid des imprimantes multifonctions exposant du SMB1 ?

Remplacez‑les ou isolez‑les sur un VLAN dédié et utilisez un relais d’impression moderne (CUPS + smbprn://) pour désactiver SMB sur le réseau utilisateur.

Points d’attention complémentaires

Documentation interne : consignez toute dérogation au standard de sécurité.
Plan de retrait : programmez un contrôle trimestriel des partages RequireSignature=0.
Roadmap Microsoft : l’équipe SMB affiche clairement son objectif 2026 : signature obligatoire + chiffrement par défaut pour tout accès invité.
Compatibilité applicative : testez les anciens scanners, clients SAPGUI 7.60, appliances IPMI exposant du SMB2.

Conclusion

Le blocage rencontré n’est pas un bug mais l’aboutissement logique de la stratégie « Secure by Design » de Microsoft. Désactiver la signature côté client ne doit être qu’un palliatif. La démarche pérenne consiste à mettre à jour Samba/NAS, activer la signature (mandatory) et profiter d’une intégrité renforcée sans impact notable sur les performances. Anticiper dès aujourd’hui évitera des interruptions le jour où la signature deviendra incontournable sur l’ensemble du parc Windows.

Impossible de mapper un partage Samba depuis Windows Server 2025 : causes, solutions et bonnes pratiques

Impossibilité de mapper un partage Samba depuis Windows Server 2025