Comment puis-je diagnostiquer la différence de connectivité SMB entre les serveurs ?

Windows Server & IT Pro Windows Server 2022 & antérieur
1

Contexte

J’ai hérité d’un groupe de serveurs Windows Server 2019 récemment. La configuration n’est… pas idéale. Ils font tous partie d’un groupe de travail, myworkgroup, mais il n’y a pas de domaine impliqué. Chacun a son propre compte administrateur local, theadmin. Tous les comptes locaux theadmin ont le même mot de passe. Un serveur a un dossier partagé activé.

La disposition générale ressemble à ceci :

  • ServerA

  • Partage de fichiers : C:\Shared (nom : “Shared”)

  • Admin local : ServerA\theadmin (même mot de passe, par ex. redactedpw1234)

  • ServerB

  • Admin local : ServerB\theadmin (même mot de passe, par ex. redactedpw1234)

  • ServerC

  • Admin local : ServerC\theadmin (même mot de passe, par ex. redactedpw1234)

  • ServerQA

  • Admin local : ServerQA\theadmin (même mot de passe, par ex. redactedpw1234)

Le défi

À un moment donné — difficile à déterminer exactement quand — le compte theadmin de ServerQA peut désormais lire depuis \\ServerA\Shared, mais ne peut pas modifier ou supprimer des fichiers (j’ai constaté un problème avec une tâche planifiée exécutée sous ce compte, puis vérifié via l’explorateur Windows en étant connecté avec ce compte).

Les comptes theadmin de ServerB et ServerC ne semblent pas avoir ce problème. Lorsque je suis connecté au compte local theadmin sur ces deux machines, je peux regarder \\ServerA\Shared et modifier/créer/supprimer des fichiers comme prévu.

Mon défi peut donc se résumer ainsi :

  • :white_check_mark: ServerB, ServerC et ServerQA semblent avoir la même configuration

  • :white_check_mark: ServerB peut accéder à \\ServerA\Share dans l’explorateur Windows et créer/modifier des fichiers

  • :white_check_mark: ServerC peut accéder à \\ServerA\Share dans l’explorateur Windows et créer/modifier des fichiers

  • :cross_mark: ServerQA peut lire \\ServerA\Share dans l’explorateur Windows mais reçoit une erreur de permission lorsqu’il tente de créer ou modifier des fichiers.

Ce que j’ai essayé

  • Redémarrer le serveur ServerQA

  • Get-SmbConnection sur tous les serveurs.

  • Le schéma de configuration semble être le même sur ServerB, ServerC et ServerQA — L’utilisateur est listé comme [LaMachine]\theadmin dans chaque cas, et les identifiants sont les mêmes. Ils utilisent donc tous leurs identifiants locaux theadmin.

  • Le dialecte est 3.1.1 pour toutes les machines.

  • Get-SmbMultichannelConnection semble montrer le même schéma pour toutes.

  • Interface index [L'index Ethernet1 du serveur], RSS: True, RDMA: False

  • Essayé de supprimer et rétablir le partage

  • Sur ServerQA, net use /delete \\ServerA\Shared

  • Sur ServerA, Get-SmbSession puis Close-SmbSession pour fermer toutes les sessions de cette machine

  • Sur ServerQA, net use \\ServerA\Shared /user:ServerQA\theadmin redactedpw1234 pour rétablir

  • Sur ServerQA, net use et Get-SmbConnection pour confirmer que tout est configuré comme prévu

  • Exécuté whoami /all sur tous les serveurs et vérifié que les comptes locaux sont tous dans les mêmes groupes locaux.

  • Vérifié les journaux d’événements SMBClient et SMBServer sur les serveurs respectifs. Rien de remarquable.

  • Vérifié le registre. Tous les serveurs ont les mêmes valeurs dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

  • Bien que je puisse manquer un autre endroit où chercher ?

  • Get-SmbClientConfiguration renvoie exactement le même résultat sur tous les serveurs

  • Installé le module PowerShell NTFSSecurity et exécuté Get-NTFSEffectiveAccess -Path \\ServerA\Shared depuis tous les serveurs. Tous ont renvoyé le même résultat.

  • Sur ServerA, exécuté icacls "C:\Shared". Cela a renvoyé ServerA\theadmin comme ayant accès, mais aucun des comptes admin spécifiques des autres machines. Je suppose donc que ce n’est pas aussi pertinent.

  • Sur ServerA, exécuté Get-SmbShareAccess -Name "Shared". L’utilisateur ServerA\theadmin était dans les résultats mais aucun des utilisateurs theadmin des autres machines n’est mentionné spécifiquement.

  • Exécuté secedit /export /cfg c:\Windows\temp\secpol.cfg sur ServerB et ServerQA et comparé les résultats. Il y a des différences dans les privilèges, mais pour autant que je puisse en juger, elles semblent refléter des SID locaux. Je suis moins familier avec cela cependant.

  • Sur chaque serveur, exécuté gpresult /h et comparé les fichiers HTML. Pour autant que je puisse en juger, il n’y a pas de différences.

  • Suite à une excellente tentative de réponse ci-dessous, j’ai vérifié le registre du serveur ServerQA pour voir si HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy était défini sur 1 comme il devrait l’être. Malheureusement, c’est déjà le cas.

Compte tenu de tout ce qui précède, comment puis-je déterminer quelle est la différence entre l’accès depuis ServerQA par rapport à ServerB ou ServerC dans cette situation ? Y a-t-il des outils supplémentaires que je devrais envisager ? Y a-t-il un point de dépannage courant qui m’échappe pour déterminer la différence entre les serveurs ? Je suis perdu.

Mise à jour — on se rapproche ?

Après avoir redémarré ServerA (qui héberge le partage de fichiers) et ServerQA (le client problématique), les symptômes ont semblé disparaître pendant environ 10 minutes. J’ai pu modifier des fichiers et voir les tâches planifiées s’exécuter comme prévu en modifiant des fichiers. Puis les symptômes sont revenus sans aucune action de ma part, et sont restés ainsi.

2

Le mystère semble être résolu — et c’était quelque chose que je n’avais pas anticipé, mais que moi et d’autres pourrions trouver utile à l’avenir.

L’essentiel ici est probablement de noter que j’ai hérité de ces serveurs.

J’avais vérifié les paramètres de Windows Defender des serveurs. Ce que je n’avais pas réalisé, c’est que notre prestataire de services gérés utilise également l’antivirus Sophos — et que je n’avais pas de visibilité sur ces journaux. Ils sont également censés nous alerter lorsque des problèmes surviennent, mais semblent avoir échoué à le faire dans ce cas.

Sophos a incorrectement signalé notre activité, qui modifie de nombreux fichiers, comme une attaque par rançongiciel. Par conséquent, l’antivirus prenait des mesures pour empêcher l’activité, ce qui explique la nature transitoire du problème et le fait qu’il se résolvait souvent de lui-même pour échouer à nouveau après un certain temps.

L’ajout de cet emplacement à une liste d’exceptions pour ce produit a semblé résoudre ces problèmes.

Merci à tous ceux qui ont travaillé à identifier la cause ! Espérons que les étapes identifiées ici seront utiles à d’autres à l’avenir.