Score:1

Windows 10 clients flooding Samba servers with phantom guest login attempts

my flag

I am currently running a Samba server for file sharing on a SOHO network.

I have noticed that one of the recent patches to Windows 10 seems to have introduced some sort of nasty bug with SMB that causes Windows 10 to spam unauthenticated guest requests at the SMB server for every file accessed.

The errors I get in the Samba logs are as follows:

[2021/12/22 18:31:42.283148,  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 (MY_USERNAME)
[2021/12/22 18:31:42.283174,  1] ../../source3/smbd/service.c:545(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_ACCESS_DENIED

Over on the Windows 10 client, I see the event viewer under Applications and Services Logs -> Microsoft -> Windows -> SMBClient -> Security filling up with the following errors:

The SMB client failed to connect to the share.

Error: {Access Denied}
A process has requested access to an object, but has not been granted those access rights.

Path: \smb\MY_USERNAME

This bug appears to have been introduced sometime in the past couple of months during a KB rollup, since a fresh install of Windows 10 does not provoke this behavior- only a fully updated installation will.

I want to be clear about a couple of things:

  1. The client authenticates with the server just fine. My network shares work great, so I don't think this is a credential issue. Nevetheless, Windows 10 is constantly spamming Samba with unauthenticated guest login attempts on every file access.

  2. Guest access has NOT been enabled in Windows 10. It is disabled by default and I haven't overridden it using GPOs.

  3. Windows Defender isn't configured to scan network shares. Administratively disabling that function doesn't seem to change anything.

  4. I've tried outright disabling guest access in Samba, and I've tried enforcing encryption/server signing as well (which disables guest access entirely). Despite this, I still get phantom guest login attempts from the Windows 10 clients (though the error changes on the Samba server to say something about guest access being blocked due to encryption).

Again, I can login to the file server just fine and things do work- except for the bit where Windows 10 appears to be attempting to spawn a guest login for every file accessed.

Is there any way to fix this behavior on either the Samba or Windows 10 client side? I've seen some similar reports of this online, but thus far no solutions and I haven't been able to find anything in smb.conf that would "fix" this (apparent?) bug.

Jevgenij Martynenko avatar
us flag
Please run on any of your Windows machines: `ICALCS \\SMBSERVER\SHARENAME`. What permissions do you get for user/group accessing this foldet from Win machines? Is SYNCHRONIZE (S) permission included?
CMPXCHG8B avatar
my flag
icalcs returns the following for my home directory on the SMB server: ```C:\Users\MY_USERNAME>icacls \\smb\MY_USERNAME \\smb\MY_USERNAME S-1-5-21-2709743590-1606674597-4048815383-1000:(F) S-1-22-2-1000:(RX) Everyone:(RX) Successfully processed 1 files; Failed processing 0 files```
Score:1
id flag

I haven't done the regression testing of rolling back to old versions of windows, but I can share that I'm seeing the same problem here, with Win 10 19044.1415 connecting to a TrueNAS Core 12 box. It works, but it certainly creates some noisy logs:

[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

Per a previous commenter's question, my ICACLS output:

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

EDIT: This issue from November 2020 (!) seems very similar: https://docs.microsoft.com/en-us/answers/questions/122178/windows-10-sends-unauthenticated-smb-requests.html

Also, in my case, unfortunately the client logs the same error (SMBClient Error code 31010) in the Windows event log for every single error that shows up in the samba server logs.

EDIT 2: Possible success?

I've been able to get this behavior to stop by disabling Windows Defender real-time inspection globally on the Win10 client. I haven't yet discovered any tweaks to Defender settings that allow me to leave it enabled but not produce this behavior - for example, mapping a drive to the share and excluding that mapped drive from scanning in Defender settings does /not/ work.

EDIT 3: The only long-term workaround I've found so far (that doesn't require killing all real-time malware protection) is to give in and enable guest logins for SMB shares. This lets the broken Windows behavior continue without triggering a flood of errors, and the rest of my Samba setup doesn't permit a guest to access anything (the guest user maps to 'nobody' and the filesystem ACLs are all chmod xx0) so this works fine for me. YMMV.

Interestingly, after this change, the Windows client now logs a complaint in the event log (once per share connection) that the remote SMB server is permitting guest connections when it really shouldn't...oh, the irony.

CMPXCHG8B avatar
my flag
I'm not at home right now so I can't check my own setup, but it looks like you might be onto something- there's a GPO under Computer Config -> Administrative Templates -> Windows Components -> Windows Defender Antivirus -> Real-time Protection -> "Configure monitoring for incoming and outgoing file and program activity" that looks like it might be promising. I'd previously noticed on my own setup that I was only getting the log noise on file write, not read, so I'm assuming the outgoing direction is the one that is at fault here since incoming data is probably checked on the client itself.
id flag
An interesting lead...I tried changing that GPO on the client to only scan incoming files, rebooted, and tested, but that didn't work. I did find another workaround which is in "edit 3" above which may or may not be feasible in your environment.
Score:0
us flag

I am the person who posted the question on the Q&A Microsoft Webiste on November 2020. As you can see our issues do match and I believe is the same one. I am still fighting with the issue, because I could not find the time to really report this issue to Microsoft. In the meantime I tried other Samba setting without luck.

Today I was looking up this issue again. I stumbled on this discussion which seemed promising, but adding restrict anonymous = 1 to Samba configuration did not help. Then I've got here and I'm happy other people have noticed this problem.

I could still update my testing and call Microsoft to report the issue, but the road to get to the real engineers is very very long. (source: I worked in Customer Support and deal with it every day).

Is very annoying and I'm sure many people have this silent issue. I think we could also try older W10 versions to find out when it began.

MrCalvin avatar
cn flag
I have the same issue and also tracked it down to Defender Real-time protection. It would be interesting to know if this is also happens in domain environment (I'm running a standalone samba server)?
MrCalvin avatar
cn flag
In W10 21H2 you have the option to add path to the Defender Exclusions list, it didn't help. Also tried to block `MsSense.exe` and `NisSrv.exe` (defender services) in Windows firewall, didn't help either, it still gets through :-(
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.