Windows Cannot Access an SMB Share Using an IP Address

Question

Windows Cannot Access an SMB Share Using an IP Address

Sarah Williams 40

Users can access an SMB share through its hostname but fail when connecting through the server's IP address. How can I investigate authentication protocol differences, NTLM restrictions, and SMB connection behavior?

0 comments

2 answers

Your answer

Answer 1

When hostname access works but IP-based access fails, the most likely difference is authentication: hostname access can use Kerberos, while IP-based access often cannot and may fall back to NTLM. If NTLM is blocked or restricted, the IP-based connection can return Access Denied even though the hostname works.

Use this investigation path on the SMB client:

Check the current SMB error and target.
```
   net use
```
Look for the failing mapping and whether it reports System error 5, Access is denied, or STATUS_ACCESS_DENIED (0xC0000022).
Inspect active or attempted SMB sessions.
```
   Get-SmbConnection
```
This shows existing SMB connections and dialect details.
Review the client SMB security posture.
```
   Get-SmbClientConfiguration
```
Check settings related to signing, guest access, NTLM, and encryption.
Review SMB client event logs. Open Event Viewer > Applications and Services Logs > Microsoft > Windows > SMBClient and inspect the Connectivity and Security channels. The event ID and message identify which SMB security condition is blocking access.
Test the authentication-path difference directly.
- Connect using the server's hostname or FQDN.
- Connect using the server's IP address. If hostname works and IP fails, that matches the documented case where Kerberos is available by name but not by IP, causing the IP-based connection to depend on NTLM.

For NTLM restrictions, this is the documented condition:

It applies when connecting by IP address, to a workgroup device, or to a NAS where Kerberos cannot be used, on clients with SMB NTLM blocking configured.
The recommended resolution is to connect by the server's Kerberos-capable name (FQDN) instead of IP, and ensure name resolution and SPNs are correct.
If legacy targets must be accessed and NTLM blocking is in effect, configure an NTLM exception list for those required targets.

Also check whether the issue started after an upgrade to Windows 11 24H2 or Windows Server 2025. Those versions introduced stricter SMB defaults, including:

SMB signing required by default in some cases
SMB client NTLM blocking available
SMB encryption required by default for outbound SMB client connections

If the target is a third-party NAS or older SMB server, compare whether the failure is only with IP-based access or with all access methods. If only IP fails, focus first on Kerberos vs. NTLM behavior. If both fail, also investigate signing or encryption compatibility.

A concise interpretation guide:

Hostname works, IP fails: investigate Kerberos vs. NTLM fallback first.
Event logs mention unauthenticated guest access or Event ID 31017: the target is relying on guest access, which modern Windows blocks by default.
Failure began after OS upgrade: review SMB hardening defaults first.
Third-party NAS or workgroup target: NTLM restrictions are especially relevant.

References:

Answer 2

Hello Sarah,

This behaviour is often related to differences in authentication between hostname-based and IP-based SMB connections, particularly Kerberos and NTLM. When connecting through a hostname, Windows can use Kerberos if a valid CIFS SPN is registered, whereas connecting through an IP address typically falls back to NTLM, which may be blocked by domain security policies. I'd first run klist to check Kerberos tickets, then use Get-SmbConnection to inspect the active SMB connections and their authentication details. You should also review the policies under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options, particularly Network security: Restrict NTLM on both the client and server, and check the relevant NTLM operational logs in Event Viewer. To verify the Kerberos configuration, run setspn -Q cifs/servername and confirm that the CIFS SPN is registered against the correct computer or service account. Also, check whether SMB signing requirements, firewall rules, or existing cached credentials are affecting the connection; avoid enabling unrestricted NTLM or disabling security policies just to make IP-based access work. In most domain environments, using the server hostname or FQDN is the recommended approach because it supports Kerberos authentication and avoids unnecessary NTLM fallback.

For reference:

Microsoft Learn: SMB Security

Microsoft Learn: Restrict NTLM

Microsoft Learn: SetSPN

Hope this helps!

Harry P.