Windows 10 sends unauthenticated SMB requests

Question

Hi,

I've discovered Windows 10 sends unauthenticated SMB requests to my server and this causes logs to be written on either sides.
According to this article, Windows 10 should not send unauthenticated (GUEST) requests, but it happens.

To my understanding, these calls are done when the system is performing some actions on my behalf. I've identified:

• Antivirus (Avira) scanning for network paths while I am browsing them
• Windows File History when accessing and backing up files.

I can use my file shares without issues, but there are a ton of logs that are reported either sides and that's very annoying.

Windows Side:
Windows Event Viewer logs errors under SMB-Client.
The error says:

Error: {Access Denied}  
  
A process has requested access to an object, but has not been granted those access rights.  
  
Path: \nas\data  
  
Error code: 31010  

Samba Side
Samba side, verbose logging

Mapping user []\[] from workstation  
attempting to make a user_info for  ()  
made a user_info for  ()  
check_ntlm_password:  Checking password for unmapped user []\[]@[PC-OLIVER] with the new password interface  
check_ntlm_password:  mapped user is: []\[]@[PC-OLIVER]  
auth_check_ntlm_password: anonymous authentication for user [] succeeded  
Auth: [SMB2,(null)] user []\[] at [Thu, 10 Sep 2020 19:47:59.018110 CEST] with [(null)] status [NT_STATUS_OK] workstation [PC-OLIVER] remote host [ipv4:192.168.0.100:49239] became [NAS]\[nobody] [S-1-5-21-1308971618-3954224730-4125826118-501]. local host [ipv4:192.168.0.101:445]  
check_ntlm_password:  guest authentication for user [] -> [] -> [nobody] succeeded  
  
Successful AuthZ: [SMB2,NTLMSSP] user [NT AUTHORITY]\[ANONYMOUS LOGON] [S-1-5-7] at [Thu, 10 Sep 2020 19:47:59.018445 CEST] Remote host [ipv4:192.168.0.100:49239] local host [ipv4:192.168.0.101:445]  

Non verbose logging

create_connection_session_info: guest user (from session setup) not permitted to access this share (data)  
  
create_connection_session_info failed: NT_STATUS_ACCESS_DENIED  

I also turned on Wireshark and confirmed that my PC is indeed sending empty AuthN requests:

I tried to edit settings that are already enabled by default and should not allow anonymous requests over the network.
secpol.msc > local policies > security options:

• Network access: do not allow anonymous enumeration of SAM accounts: ENABLED
• Network access: do not allow anonymous enumeration of SAM accounts and shares: ENABLED

I also tried deleting credentials from Credential Manager, removing all shares with the command

net use */Delete  

and then using something like

net use z: \\servername\path /USER:username  

Additional details:

I've replicated this issue using Windows 10 2004 and 1903 fresh installs with two Samba servers: an existing one and another configured from scratch just for this scenario.

• Server: Linux, Debian 10, Samba 4.9.5
• Client: Windows 10 2004

When accessing the share for the first time I am prompted from credentials and I enable the option to save them in Credentials Manager.

Answer 1

Hi,

Based on your situation, the network trace collection is necessary to analyze the issue deeply.

However, analysis of network trace is beyond our forum support level. So after discussion with my colleagues, we suggest you open a case with Microsoft where more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.

You may find phone number for your region accordingly from the link below:

https://support.microsoft.com/en-us/help/4051701/global-customer-service-phone-numbers

Best Regards,
Sunny

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Hi,

did you find the solution for this issue? I am also struggling with it.

Best Regards,
Viktor

Answer 3

I am still struggling with this. However in my case the shares are NOT functioning normally.

I am seeing a large mount of concurrency and file state issues when using the shares under load, such as running an IDE workspace on them.

Examples are things like:
IsADirectoryError: [Errno 21] Is a directory: '\\10.0.0.199\paul\devel\home_auto\home_heating\venv\Lib\site-packages\setuptools\command\__init__.py'

It is not a directory. It's a file. Pycharm was trying to write to it, it suddenly became a directory and now it's an empty file, corrupted.

or:
NotADirectoryError: [WinError 267] The directory name is invalid: '\\10.0.0.199\paul\devel\home_auto\home_heating\venv\Lib\site-packages'

When.. you guessed it, it is indeed a directory. In fact it's the same directory the application just created in the previous step!

So, no they are not functioning correctly they are riddled with concurrent access issues, race conditions and files appearing, disappearing constantly. If you run an application which monitors files for updates, you will see files appearing and disppearing.

I expect the two accesses, the real auth access + this bug spammed GUEST access are not always happening the same order. So the response back to the client libraries is ambigous. It seems in most instances the application get an "OK" for a file access when it fact the server rejected it as guest access. Causing file state and content corruption.

It needs to be fixed or at least tracked down to how it gets created on at least some peoples machines.

Allowing guest access to the shares, fixes the problem. But that is NOT a viable solution.

Other examples of the madness this causes.

Deleting a project from eclipse and it told me that main.cpp directory was not empty and that the src folder could not be deleted because it referred to itself. I'm not joking. Absolute in sanity. Thankfully on backed up "workspace" files.

Answer 4

Interestingly, it seems as though out of 3 windows PCs this only occurs on one of them. The most recently installed (from MS media creator) a month ago.

Answer 5

FYI, according by NVIDIA shield devs, this is caused by a recent windows 10 update causing windows defenser and virus scanner.

More info here