Bug 15962 - SMB3 SESSION SETUP responses must always be signed
Summary: SMB3 SESSION SETUP responses must always be signed
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL: https://lists.samba.org/archive/cifs-...
Keywords:
Depends on:
Blocks:
 
Reported: 2025-12-02 20:23 UTC by Kacper
Modified: 2026-01-10 19:11 UTC (History)
3 users (show)

See Also:


Attachments
Decrypted SMB3 Session Setup - Samba (60.35 KB, image/png)
2026-01-09 11:47 UTC, Kacper
no flags Details
Decrypted SMB3 Session Setup - Windows Server 2019 (76.44 KB, image/png)
2026-01-09 11:48 UTC, Kacper
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kacper 2025-12-02 20:23:11 UTC
Windows 11 does not apply group policies at logon when Hardened UNC paths are configured with RequireMutualAuthentication=1 (Computer Configuration/Administrative Templates/Network/Network Provider, Hardened UNC Paths). This works without issues on Windows 10.

It appears that access to the SYSVOL share fails during logon. Error 2148073478 / Invalid Signature is logged in the Windows event log for the SYSVOL UNC path. According to https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/error-messages-smb-connections
 this error is related to the Secure Negotiate feature added to SMB 3.0 in Windows Server 2012 and Windows 8, but that predates Windows 10, which works correctly, and I am fairly certain Samba already supports this SMB3 feature.

Tested on 4.21.9 and 4.23.3.
Comment 1 Kacper 2025-12-02 20:23:49 UTC
Microsoft Customer Service and Support suggested it might be related to issue #15876, but that does not seem accurate because that security hardening was focused on Samba running as a member server in a Windows Active Directory environment, where Microsoft introduced schannel hardening changes on the server side. Microsoft support declined to investigate further, stating that Samba falls outside their support scope. I understand their position, but I was hoping they could explain why Windows behaves this way and whether SMB3 signing is failing or something else is occurring.

I hope dochelp will be more willing to assist with troubleshooting.
Comment 2 Kacper 2026-01-09 08:57:38 UTC
After troubleshooting with dochelp, we determined that the SESSION SETUP responses must always be signed, even when they are encapsulated within an SMB transform (e.g., when encryption is enabled).

See https://lists.samba.org/archive/cifs-protocol/2026-January/004670.html.
Comment 3 Stefan Metzmacher 2026-01-09 10:48:24 UTC
Do you have a network capture with decryption keys,
it would be good to look at how this happens.

Is this a multi-channel bind request or reauth?

See https://wiki.samba.org/index.php/Wireshark_Decryption
Comment 4 Kacper 2026-01-09 11:47:38 UTC
Created attachment 18794 [details]
Decrypted SMB3 Session Setup - Samba
Comment 5 Kacper 2026-01-09 11:48:04 UTC
Created attachment 18795 [details]
Decrypted SMB3 Session Setup - Windows Server 2019
Comment 6 Kacper 2026-01-09 11:57:40 UTC
(In reply to Stefan Metzmacher from comment #3)

I have network captures for both Samba ↔ Windows 11 and Windows Server 2019 ↔ Windows 11, and I also have the corresponding decryption keys. I’ve attached screenshots for the Session Setup response traces to this issue.

I’m a bit hesitant to share the full network captures publicly. While they shouldn’t contain any sensitive information, they weren’t captured entirely in isolation, so I’d feel more comfortable not posting them openly. If needed, I can send the full captures to you via email.

This happens during reauth.
Comment 7 Stefan Metzmacher 2026-01-10 19:11:44 UTC
(In reply to Kacper from comment #6)

Thanks! I think that's enough to reproduce it.