Windows 11: "Your organization's security policies block unauthenticated guest access" when opening a NAS share (0x80070035)

Hi, it's BlueByte. You type \\nas01\scans into File Explorer on a freshly upgraded Windows 11 laptop and get a dialog instead of a folder: You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network. A colleague's older laptop opens the same share without complaint. Nothing is broken and the NAS is reachable; your SMB client is refusing on purpose. We'll walk through what it refuses and why, how to tell this refusal apart from an SMB1-only device and from a plain name-resolution failure, the fix Microsoft wants you to make, the escape hatch and what it costs, and how to stop it coming back.

One refusal, three wordings: the dialog, 0x80070035 and error 3227320323

Microsoft's SMB signing documentation lists the messages you can get from a device that uses guest accounts to simplify access: the dialog above, Error code: 0x80070035 The network path was not found., and from net use, System error 3227320323 has occurred. The second one is confusing because 0x80070035 is the generic "network path not found" code that also appears for typos and dead hosts. What settles it is the client's own log: the docs list Event ID 31017 in Microsoft-Windows-SmbClient/Security with the text Rejected an insecure guest logon. The machine attempted to connect to the server using an insecure guest logon. The server denied the connection. If that event is there, you are in this article; if it isn't, treat that as inconclusive on older builds, where the docs tie this auditing to Windows 11 24H2 and Server 2025.

Why the client refuses: guest logons are off, and 24H2 also demands signing

Two defaults stack up. Since Windows 10 version 1709 and Windows Server 2019, the SMB2 and SMB3 client no longer allows guest account access to a remote server, nor falling back to Guest after invalid credentials. The docs spell out the editions: Windows 10 Enterprise, Education and Pro for Workstations, Windows Server 2019 Datacenter and Standard, and Windows 11 Pro from Insider build 25267 onward, which is why a Windows 11 Pro machine on 24H2 refuses while Windows 10 Home and Pro still allow guest. The reason: a guest logon lets an attacker put up a spoofed server without any credential error, and guest sessions can't use signing or encryption, so they are open to adversary-in-the-middle attacks.

The second default arrived with Windows 11 version 24H2: Enterprise, Pro and Education now require both outbound and inbound SMB signing, and Windows Server 2025 requires outbound signing; Home requires neither. Guest logons don't support signing even when the client allows guests, so on 24H2 flipping the guest switch alone isn't enough, and a third-party server that doesn't sign at all fails with 0xc000a000, STATUS_INVALID_SIGNATURE or The cryptographic signature is invalid.

Rule out the two look-alikes: an SMB1-only device and error 53

An old NAS or printer that only speaks SMB1 produces different text: The specified network name is no longer available., Unspecified error 0x80004005, System Error 64 or Error 58, and Windows 11 doesn't include the SMB1 client at all after a clean install. The client logs Event ID 32000, SMB1 negotiate response received from remote device when SMB1 cannot be negotiated by the local computer. The other look-alike is System error 53 has occurred. The network path was not found. with no dialog and no 31017: the documented cause is the TCP/IP NetBIOS Helper service stopped or running as Local System instead of Local Service, and more generally the name didn't resolve or TCP 445 is blocked. Credentials never came into it.

Confirm which one you have with Get-SmbClientConfiguration and the SmbClient log

Run these from an elevated PowerShell on the machine that fails:

Get-SmbClientConfiguration | Format-List EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-SmbClient/Security'; Id = 31017, 32000 } -MaxEvents 20 |
  Format-List TimeCreated, Id, Message
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Format-List FeatureName, State
Test-NetConnection -ComputerName nas01 -Port 445 | Format-List ComputerName, RemoteAddress, TcpTestSucceeded

On a Windows 11 Pro 24H2 machine you should see something like:

EnableInsecureGuestLogons : False
RequireSecuritySignature  : True
 
TimeCreated : 22/09/2026 09:14:02
Id          : 31017
Message     : Rejected an insecure guest logon. ...
 
FeatureName : SMB1Protocol
State       : Disabled
 
TcpTestSucceeded : True

Read it as a tree. TcpTestSucceeded : False means the host or port isn't reachable and this is the error-53 family, not guest access. A 32000 event with SMB1 Disabled means the device is SMB1-only. A 31017 event with EnableInsecureGuestLogons : False is the guest block, and RequireSecuritySignature : True tells you whether you are also on the signing requirement.

The fix Microsoft recommends: give the share an account and turn on signing

Stop using guest. Create a user on the NAS, grant it the share, disable guest on that share, and connect with the credential:

net use S: \\nas01\scans /user:nas01\scanuser /persistent:yes
Get-SmbConnection -ServerName nas01 | Format-List ServerName, ShareName, UserName, Credential, Dialect

ServerName : nas01
ShareName  : scans
UserName   : LAPTOP-7\haneul
Credential : nas01\scanuser
Dialect    : 3.1.1

Credential is the account the session was set up with; a guest session would not have got this far. Then check the NAS firmware for an SMB signing setting and turn it on (on Samba-based devices this is the server signing option), so a 24H2 client can sign the session. The signing docs are explicit that the answer to a non-signing third party is to enable signing on the server, or update or replace the device, not to weaken the client.

The escape hatch: allow insecure guest logons, and what it costs you

If the device offers nothing but guest and you accept the risk on that client, Microsoft documents the switch:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force
# Windows 11 24H2 Enterprise/Pro/Education only, and only if the device also can't sign:
Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

The same two settings live in Group Policy at Computer Configuration → Administrative Templates → Network → Lanman Workstation → Enable insecure guest logons and Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Microsoft network client: Digitally sign communications (always); the registry form of the first is HKLM\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation\AllowInsecureGuestAuth as a DWORD of 1. If a domain GPO sets the policy, it takes precedence over the local value, so change the GPO rather than the machine. The docs add that both SMB signing and SMB encryption policies must be disabled for guest logons to work, and that the client then logs 31018 An administrator has enabled AllowInsecureGuestAuth as a warning. That is the cost: this client can no longer tell a spoofed server from the real one, for every share it opens.

A worked example: the office NAS after the 24H2 upgrade, checked end to end

A team's Windows 11 Pro laptops move from 23H2 to 24H2 and \\nas01\scans, a guest share on a small NAS, stops opening with the dialog; a 23H2 laptop still opens it. If you check it yourself, Get-SmbClientConfiguration shows EnableInsecureGuestLogons : False and RequireSecuritySignature : True, the log shows 31017 at each attempt, and Test-NetConnection on port 445 succeeds. The admin creates scanuser on the NAS, gives it read/write on scans, turns guest off for that share, and pushes the credential with cmdkey /add:nas01 /user:nas01\scanuser /pass:<password>. The NAS turns out to support signing once its firmware is updated, so the 24H2 signing requirement never has to be touched. Then confirm three things: no new 31017 appears in Microsoft-Windows-SmbClient/Security, Get-SmbConnection lists the share with Credential : nas01\scanuser, and Get-SmbClientConfiguration still reports EnableInsecureGuestLogons : False and RequireSecuritySignature : True. If you took the escape hatch instead, expect 31018 and 31022 (Allowed an insecure guest logon) in that log; that is the client telling you it is trusting the server on faith.

Keep it from coming back

Treat guest shares as a migration item, not a setting. Put per-user accounts on every NAS and printer share, enable signing on the device, and retire hardware whose vendor won't add SMB2 or signing support; Microsoft's SMB1 Product Clearinghouse lists vendors and the updates that removed those requirements. On a fleet, keep Enable insecure guest logons disabled in the domain GPO, and if one exception is unavoidable, scope it to a security group of the affected machines rather than the domain. On 24H2 and Server 2025, audit guest attempts in the SmbClient/Security log before the next hardware refresh.

How this differs from "You do not have permission" and from a signature error

You do not have permission to access \\nas01 means the client authenticated and the server said no: share or NTFS permissions on the server side, and the documented checks are the share's permissions and the TCP/IP NetBIOS Helper service. 0xc000a000 / The cryptographic signature is invalid means the session was not guest but the server refused or mangled signing, which is a server setting to fix. The guest-access dialog means the client never presented a credential the server accepted and refused to fall back to Guest, which is exactly what the 31017 event records.

Next time a share opens on one laptop and not another, walk these checks back in order: is the host reachable on 445, is there a 31017 or a 32000, what do the two client settings say, and only then decide between an account on the device and the switch you know the price of.