Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

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

ayi

<h2><a name="p-34101-contexte-1" class="anchor" href="#p-34101-contexte-1" aria-label="Heading link"></a>Contexte</h2>
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, <code>myworkgroup</code>, mais il n’y a pas de domaine impliqué. Chacun a son propre compte administrateur local, <code>theadmin</code>. Tous les comptes locaux <code>theadmin</code> ont le même mot de passe. Un serveur a un dossier partagé activé.
La disposition générale ressemble à ceci :
<ul>
<li>
ServerA
</li>
<li>
Partage de fichiers : <code>C:\Shared</code> (nom : “Shared”)
</li>
<li>
Admin local : <code>ServerA\theadmin</code> (même mot de passe, par ex. <code>redactedpw1234</code>)
</li>
<li>
ServerB
</li>
<li>
Admin local : <code>ServerB\theadmin</code> (même mot de passe, par ex. <code>redactedpw1234</code>)
</li>
<li>
ServerC
</li>
<li>
Admin local : <code>ServerC\theadmin</code> (même mot de passe, par ex. <code>redactedpw1234</code>)
</li>
<li>
ServerQA
</li>
<li>
Admin local : <code>ServerQA\theadmin</code> (même mot de passe, par ex. <code>redactedpw1234</code>)
</li>
</ul>
<h2><a name="p-34101-le-dfi-2" class="anchor" href="#p-34101-le-dfi-2" aria-label="Heading link"></a>Le défi</h2>
À un moment donné — difficile à déterminer exactement quand — le compte <code>theadmin</code> de ServerQA peut désormais lire depuis <code>\ServerA\Shared</code>, 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 <code>theadmin</code> de ServerB et ServerC ne semblent pas avoir ce problème. Lorsque je suis connecté au compte local <code>theadmin</code> sur ces deux machines, je peux regarder <code>\ServerA\Shared</code> et modifier/créer/supprimer des fichiers comme prévu.
Mon défi peut donc se résumer ainsi :
<ul>
<li>
<img src="https://forum-microsoft.fr/images/emoji/twitter/white_check_mark.png?v=15" title=":white_check_mark:" class="emoji" alt=":white_check_mark:" loading="lazy" width="20" height="20"> <code>ServerB</code>, <code>ServerC</code> et <code>ServerQA</code> semblent avoir la même configuration
</li>
<li>
<img src="https://forum-microsoft.fr/images/emoji/twitter/white_check_mark.png?v=15" title=":white_check_mark:" class="emoji" alt=":white_check_mark:" loading="lazy" width="20" height="20"> <code>ServerB</code> peut accéder à <code>\ServerA\Share</code> dans l’explorateur Windows et créer/modifier des fichiers
</li>
<li>
<img src="https://forum-microsoft.fr/images/emoji/twitter/white_check_mark.png?v=15" title=":white_check_mark:" class="emoji" alt=":white_check_mark:" loading="lazy" width="20" height="20"> <code>ServerC</code> peut accéder à <code>\ServerA\Share</code> dans l’explorateur Windows et créer/modifier des fichiers
</li>
<li>
<img src="https://forum-microsoft.fr/images/emoji/twitter/cross_mark.png?v=15" title=":cross_mark:" class="emoji" alt=":cross_mark:" loading="lazy" width="20" height="20"> <code>ServerQA</code> peut lire <code>\ServerA\Share</code> dans l’explorateur Windows mais reçoit une erreur de permission lorsqu’il tente de créer ou modifier des fichiers.
</li>
</ul>
<h2><a name="p-34101-ce-que-jai-essay-3" class="anchor" href="#p-34101-ce-que-jai-essay-3" aria-label="Heading link"></a>Ce que j’ai essayé</h2>
<ul>
<li>
Redémarrer le serveur <code>ServerQA</code>
</li>
<li>
<code>Get-SmbConnection</code> sur tous les serveurs.
</li>
<li>
Le schéma de configuration semble être le même sur ServerB, ServerC et ServerQA — L’utilisateur est listé comme <code>[LaMachine]\theadmin</code> dans chaque cas, et les identifiants sont les mêmes. Ils utilisent donc tous leurs identifiants locaux <code>theadmin</code>.
</li>
<li>
Le dialecte est <code>3.1.1</code> pour toutes les machines.
</li>
<li>
<code>Get-SmbMultichannelConnection</code> semble montrer le même schéma pour toutes.
</li>
<li>
<code>Interface index [L'index Ethernet1 du serveur], RSS: True, RDMA: False</code>
</li>
<li>
Essayé de supprimer et rétablir le partage
</li>
<li>
Sur ServerQA, <code>net use /delete \ServerA\Shared</code>
</li>
<li>
Sur ServerA, <code>Get-SmbSession</code> puis <code>Close-SmbSession</code> pour fermer toutes les sessions de cette machine
</li>
<li>
Sur ServerQA, <code>net use \ServerA\Shared /user:ServerQA\theadmin redactedpw1234</code> pour rétablir
</li>
<li>
Sur ServerQA, <code>net use</code> et <code>Get-SmbConnection</code> pour confirmer que tout est configuré comme prévu
</li>
<li>
Exécuté <code>whoami /all</code> sur tous les serveurs et vérifié que les comptes locaux sont tous dans les mêmes groupes locaux.
</li>
<li>
Vérifié les journaux d’événements SMBClient et SMBServer sur les serveurs respectifs. Rien de remarquable.
</li>
<li>
Vérifié le registre. Tous les serveurs ont les mêmes valeurs dans <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters</code>
</li>
<li>
Bien que je puisse manquer un autre endroit où chercher ?
</li>
<li>
<code>Get-SmbClientConfiguration</code> renvoie exactement le même résultat sur tous les serveurs
</li>
<li>
Installé le <a href="https://www.powershellgallery.com/packages/NTFSSecurity/4.2.6" rel="noopener nofollow ugc">module PowerShell NTFSSecurity</a> et exécuté <code>Get-NTFSEffectiveAccess -Path \ServerA\Shared</code> depuis tous les serveurs. Tous ont renvoyé le même résultat.
</li>
<li>
Sur <code>ServerA</code>, exécuté <code>icacls "C:\Shared"</code>. 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.
</li>
<li>
Sur <code>ServerA</code>, exécuté <code>Get-SmbShareAccess -Name "Shared"</code>. L’utilisateur <code>ServerA\theadmin</code> était dans les résultats mais aucun des utilisateurs <code>theadmin</code> des autres machines n’est mentionné spécifiquement.
</li>
<li>
Exécuté <code>secedit /export /cfg c:\Windows\temp\secpol.cfg</code> sur <code>ServerB</code> et <code>ServerQA</code> 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.
</li>
<li>
Sur chaque serveur, exécuté <code>gpresult /h</code> et comparé les fichiers HTML. Pour autant que je puisse en juger, il n’y a pas de différences.
</li>
<li>
Suite à une excellente tentative de réponse ci-dessous, j’ai vérifié le registre du serveur <code>ServerQA</code> pour voir si <code>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy</code> était défini sur <code>1</code> comme il devrait l’être. Malheureusement, c’est déjà le cas.
</li>
</ul>
Compte tenu de tout ce qui précède, comment puis-je déterminer quelle est la différence entre l’accès depuis <code>ServerQA</code> par rapport à <code>ServerB</code> ou <code>ServerC</code> 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.
<h2><a name="p-34101-mise-jour-on-se-rapproche-4" class="anchor" href="#p-34101-mise-jour-on-se-rapproche-4" aria-label="Heading link"></a>Mise à jour — on se rapproche ?</h2>
Après avoir redémarré <code>ServerA</code> (qui héberge le partage de fichiers) et <code>ServerQA</code> (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.
<hr>
Source : <a href="https://www.powershellgallery.com/packages/NTFSSecurity/4.2.6" rel="noopener nofollow ugc">Server Fault</a>

ayi_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.