Les clients Windows 10 inondent les serveurs Samba de tentatives de connexion fantômes d'invités

Je n'ai pas effectué les tests de régression pour revenir aux anciennes versions de Windows, mais je peux vous dire que je rencontre le même problème ici, avec Win 10 19044.1415 se connectant à un boîtier TrueNAS Core 12. Cela fonctionne, mais cela crée certainement des journaux bruyants :

[2021/12/24 21:40:18.383339,  1] ../../source3/smbd/service.c:355(create_connection_session_info)
  create_connection_session_info: guest user (from session setup) not permitted to access this share (personal)
[2021/12/24 21:40:18.383383,  1] ../../source3/smbd/service.c:544(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_ACCESS_DENIED

Selon la question d'un précédent commentateur, mon résultat ICACLS :

C:\>icacls \\nas\personal
\\nas\personal S-1-22-1-0:(F)
               CREATOR OWNER:(OI)(CI)(IO)(F)
               S-1-5-21-3997689159-3832354152-3824094002-1005:(M,DC)
               CREATOR GROUP:(OI)(CI)(IO)(M,DC)

Successfully processed 1 files; Failed processing 0 files

EDITAR: Ce numéro de novembre 2020 ( !) semble très similaire : https://docs.microsoft.com/en-us/answers/questions/122178/Windows-10-sends-unauthenticated-smb-requests.html

De plus, dans mon cas, le client enregistre malheureusement la même erreur (SMBClient Error code 31010) dans le journal des événements de Windows pour chaque erreur qui apparaît dans les journaux du serveur Samba.

EDIT 2 : Un succès possible ?

J'ai réussi à faire cesser ce comportement en désactivant l'inspection en temps réel de Windows Defender de manière globale sur le client Win10. Je n'ai pas encore découvert d'ajustements aux paramètres de Defender qui me permettent de le laisser activé sans produire ce comportement - par exemple, le mappage d'un lecteur au partage et l'exclusion de ce lecteur mappé de l'analyse dans les paramètres de Defender ne fonctionne pas.

EDIT 3 : La seule solution de contournement à long terme que j'ai trouvée jusqu'à présent (qui ne nécessite pas de supprimer toute protection contre les logiciels malveillants en temps réel) est de céder et d'activer les connexions d'invités pour les partages SMB. Cela permet au comportement brisé de Windows de se poursuivre sans déclencher un flot d'erreurs, et le reste de ma configuration Samba ne permet pas à un invité d'accéder à quoi que ce soit (l'utilisateur invité correspond à "nobody" et les ACL du système de fichiers sont toutes chmod xx0), donc cela fonctionne bien pour moi. YMMV.

Il est intéressant de noter qu'après cette modification, le client Windows enregistre maintenant une plainte dans le journal des événements (une fois par connexion de partage) indiquant que le serveur SMB distant autorise les connexions d'invités alors qu'il ne devrait pas le faire... oh, quelle ironie !

Je suis la personne qui a posté la question sur le site web Q&A de Microsoft le novembre 2020. Comme vous pouvez le constater, nos questions correspondent et je crois qu'il s'agit de la même. Je suis toujours en train de me battre avec cette question, car je n'ai pas pu trouver le temps de realmente signaler ce problème à Microsoft. Entre-temps, j'ai essayé d'autres paramètres Samba sans succès.

Aujourd'hui, je me suis penché à nouveau sur cette question. Je suis tombé sur este discussion qui semblait prometteuse, mais en ajoutant restrict anonymous = 1 à la configuration de Samba n'a pas aidé. Ensuite, je suis arrivé ici et je suis heureux d'autres personnes ont remarqué ce problème.

Je pourrais toujours mettre à jour mes tests et appeler Microsoft pour signaler le problème, mais la route pour atteindre les vrais ingénieurs est très très longue. (source : j'ai travaillé dans le support client et j'y suis confronté tous les jours).

C'est très ennuyeux et je suis sûr que beaucoup de gens ont ce problème silencieux. Je pense que nous pourrions également essayer des versions plus anciennes de W10 pour savoir quand cela a commencé.