Windows Server 2025 / Vérifier la signature SMB et chiffrer un partage de test
La signature SMB protège l'intégrité des messages ; le chiffrement SMB protège leur contenu pendant le transport. En cas d'échec de connexion, vérifiez le nom du serveur, l'authentification, les capacités des deux appareils et la session négociée avant de modifier ces protections.
Distinguez signature, chiffrement et autorisation
| Contrôle | Objectif |
|---|---|
| Signature | Détecter toute falsification des messages et aider à protéger les communications authentifiées |
| Chiffrement | Protéger le contenu du trafic de fichiers sur le réseau |
| Autorisations de partage et NTFS | Limiter les opérations qu'un utilisateur authentifié peut effectuer |
Une connexion signée n'est pas nécessairement chiffrée, et le chiffrement ne corrige pas des autorisations de fichiers trop larges. Examinez séparément les paramètres du serveur, ceux du client et la session réellement négociée. La documentation Microsoft sur la signature SMB distingue les exigences des connexions sortantes de Windows Server 2025 des paramètres du service entrant. Le rôle du serveur dans le domaine et les objets de stratégie de groupe (GPO) peuvent modifier la configuration effective.
Vérifiez les exigences avant de les modifier
Sur FS1, examinez séparément le client SMB, qui accède à d'autres serveurs, et le serveur SMB, qui présente ses propres fichiers :
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EncryptData,RejectUnencryptedAccess
Get-SmbShare -Name 'LabRead' | Select-Object Name,Path,EncryptData
RequireSecuritySignature indique si la signature est exigée ; ce paramètre ne décrit pas à lui seul une connexion active. Le chiffrement dépend aussi des réglages du partage, du serveur et du client. Consultez la documentation Microsoft sur le renforcement de la sécurité SMB pour les conditions propres aux versions utilisées.
Activez le chiffrement seulement sur le partage de test
Utilisez le partage LabRead déjà fonctionnel avec un compte du domaine. Fermez les fichiers ouverts et conservez la valeur initiale dans la même session PowerShell sur FS1 :
$previousEncryption = (Get-SmbShare -Name 'LabRead').EncryptData
Set-SmbShare -Name 'LabRead' -EncryptData $true
Get-SmbShare -Name 'LabRead' | Select-Object Name,EncryptData
Le chiffrement SMB exige des appareils compatibles SMB 3.x et des stratégies compatibles. Un appareil qui annonce SMB 3 ne prend pas forcément en charge le chiffrement. Après avoir enregistré votre travail, fermez uniquement la connexion cliente concernée, puis reconnectez-vous avec le nom habituel du serveur.
Sur CLIENT1, ouvrez \\fs1.ad.example.test\LabRead et inspectez la connexion réellement établie :
Get-SmbConnection | Where-Object ShareName -eq 'LabRead' | Select-Object ServerName,ShareName,Dialect,Encrypted
Repérez la ligne du partage, le dialecte SMB négocié et Encrypted=True. Si aucune ligne n'apparaît, ouvrez d'abord un fichier pour établir la connexion. Les droits en lecture seule restent inchangés même quand le chiffrement fonctionne.
Distinguez incompatibilité et échec d'authentification
| Symptôme | Premières vérifications |
|---|---|
| Échec de la connexion au nom | DNS, nom réel du serveur, connectivité au domaine |
| Erreur d'identifiants ou d'invité | Identité réelle, connexions stockées, prise en charge de l'authentification du périphérique |
| Échec de la signature | Prise en charge par le pair et exigence de signature du client |
| Échec après modification du chiffrement | Dialecte SMB, capacité de chiffrement, politique et détails de l'événement |
Privilégiez les noms de domaine et Kerberos lorsque c'est approprié plutôt que de contourner les problèmes d'identité via des IP ou des alias arbitraires. Pour un NAS plus ancien, vérifiez les mises à jour, la capacité de signature, le remplacement ou l'isolation au lieu de désactiver globalement la signature, d'activer l'utilisation d'invité non sécurisé ou d'activer SMB1.
Consultez les journaux d'événements SMBClient et SMBServer et notez l'heure, le partage et le compte concernés. Un refus d'autorisation se diagnostique différemment d'un échec de négociation de la sécurité.
Rétablissez uniquement le réglage modifié pour le test
Dans la même session PowerShell sur FS1, restaurez la valeur enregistrée plutôt que de désactiver systématiquement le chiffrement :
Set-SmbShare -Name 'LabRead' -EncryptData $previousEncryption
Reconnectez-vous, puis vérifiez à nouveau l'accès aux fichiers et la protection négociée. Des stratégies plus générales peuvent encore exiger le chiffrement malgré la restauration du réglage du partage. Pour un déploiement en production, évaluez ensemble la sensibilité des données, la compatibilité, les performances mesurées et les possibilités d'accès en cas d'incident.




