In build 29667.1000, the SMB functionality encountered a user authentication problem, which resulted in the inability to establish an SMB connection.

Question

In build 29667.1000, the SMB functionality encountered a user authentication problem, which resulted in the inability to establish an SMB connection.

2B Nier 0

Processor: AMD Ryzen 7 6800H with Radeon Graphics (3.20 GHz)

Installed RAM: 32.0 GB (31.2 GB usable)

System type: 64-bit operating system, x64-based processor

Pen and touch: Touch support with 10 touch points

SMB session authentication failed

Client name: \*

Client address: **

Username:

Session ID: 0x1

Status: An invalid parameter was passed to a service or function. (0xC000000D)

SPN: session setup failed before the SPN could be queried

SPN validation policy: SPN optional / no validation

Guidance:

This error occurs when you try to connect to a share using incorrect credentials.

This error does not always indicate an authorization problem, but is primarily an authentication problem. This error is more common on non-Windows clients.

This error can occur in the following situations: an incorrect username or password is used for NTLM; there is an LmCompatibility setting mismatch between the client and the server; the service principal name is incorrect; there are duplicate Kerberos service principal names; the Kerberos ticket-granting service ticket is incorrect; or the guest account is not enabled for guest access.

Additional context from the user:

I can confirm that my SMB configuration has never been modified. In addition, versions up to around July worked normally. Ever since the update in August and continuing through September, this issue has been occurring.

0 comments

2 answers

Your answer

Answer 1

Hello,

The error you’re seeing with SMB in build 29667.1000 is not a configuration mistake on your side but a regression introduced in recent Insider builds. The key detail is the STATUS_INVALID_PARAMETER (0xC000000D) during session setup, which points to a failure in how the client and server negotiate authentication parameters. Since you confirmed that your SMB configuration hasn’t been modified and it worked fine until the August builds, this rules out local misconfiguration and strongly suggests a protocol-level change or bug in the SMB stack introduced by Microsoft.

The “SPN validation policy: SPN optional / no validation” line is important. It indicates that Kerberos SPN validation isn’t the root cause here, but the failure occurs before SPN resolution. This aligns with known issues where NTLM authentication fails due to mismatched LmCompatibilityLevel or changes in how NTLM fallback is handled. In recent Insider builds, Microsoft has tightened SMB authentication defaults, particularly around guest access and NTLMv1 fallback. Non-Windows clients are especially impacted because they may still attempt NTLMv1 or send parameters that Windows now rejects outright.

At this point, the most reliable workaround is to explicitly enforce NTLMv2 on both sides. On Windows, check the registry key at:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Set it to 5 (Send NTLMv2 response only. Refuse LM & NTLM). This ensures the client only uses NTLMv2. If you’re connecting from a Linux or macOS client, make sure the SMB client library (e.g., Samba) is configured with client ntlmv2 auth = yes in smb.conf. If guest access was previously working, note that guest authentication has been disabled by default in Insider builds since mid-2024, so you’ll need to use a proper username/password.

If you’ve already aligned NTLM settings and the issue persists, then this is a regression in the Insider build itself. Microsoft has acknowledged intermittent SMB authentication failures in recent Dev Channel releases, and the fix is pending in upcoming cumulative updates. In that case, the only stable resolution is either to roll back to a pre-August build or wait for the official patch.

I recommend confirming the NTLM registry setting, checking Samba client configuration if applicable, and if the error continues, treat it as a known Insider build bug rather than a misconfiguration.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HL.

2B Nier 0 Reputation points

2026-09-21T03:04:55.92+00:00

Thanks for the reply. The issue has been resolved in the latest updated Windows version.

Answer 2

Since the issue started after August updates and SMB worked before, first treat it as a secure-by-default behavior change rather than a manual configuration change.

Identify which SMB security condition is blocking authentication on the client. Run these on the affected client:
```
   net use
   Get-SmbConnection
   Get-SmbClientConfiguration
```
Then check Event Viewer > Applications and Services Logs > Microsoft > Windows > SMBClient > Connectivity and Security. The event message and ID usually identify the exact cause.
Check for guest access being blocked. If the share or NAS previously allowed anonymous or guest access, modern Windows blocks insecure guest sign-ins by default. Typical symptom: messages about unauthenticated guest access or SMBClient Event ID 31017. The preferred fix is to connect with valid credentials instead of guest access. Re-enabling insecure guest logons is discouraged except as a temporary, risk-accepted workaround because it increases exposure to rogue-server and man-in-the-middle attacks.
Check whether SMB signing is now required. On Windows 11 24H2 and Windows Server 2025, SMB signing is required by default. If the target is a third-party server or NAS that does not support signing, authentication can fail even if credentials are correct. Preferred fix: enable SMB signing on the server or NAS. If the device cannot support signing, evaluate the security impact before changing the client requirement.
Check whether NTLM is blocked or unavailable. This commonly affects connections made by IP address, to a workgroup device, or to a NAS where Kerberos cannot be used. In that case, use the server’s Kerberos-capable name/FQDN instead of the IP address, and verify name resolution and SPNs.
If Kerberos is expected, verify name and SPN conditions. When the UNC path uses the server FQDN or NetBIOS name, Windows uses Kerberos for authentication. If session setup fails before the SPN is queried, check whether the server is being accessed by an alias or name that does not match its configured SPN. Also ensure the SMB server has an SPN when accessed through a CNAME DNS record.
If this is a workgroup or NAS scenario, check authentication compatibility. The context specifically calls out LmCompatibility setting mismatch between the client and server as a possible cause of authentication failure. If the target is a non-domain SMB server or NAS, confirm both sides support the same authentication method.
If repeated failed sign-ins have occurred, consider throttling. On Windows Server 2022+, repeated failed SMB sign-ins can be delayed by the SMB authentication rate limiter, which can look like intermittent authentication failure or slowness. Resolve the underlying bad credentials or mapping problem first.

Most likely causes for a system that worked until recent updates are:

guest access that is now blocked by default
SMB signing now being required
NTLM/Kerberos behavior changing because the connection is using IP address, workgroup naming, or a NAS

A practical end-to-end test path is:

Remove any existing failed mapping with net use.
Reconnect using the server’s name or FQDN, not its IP.
Use a known-valid username and password.
Review SMBClient event logs immediately after the failed attempt.
If the target is a NAS or third-party SMB server, verify it supports SMB signing and is not relying on guest access.