Can only access windows shares using hostnames or FQDN, cannot access using IP address of host.


I recently became the sysadmin at a company that had not previously had one. I inherited a situation where there were 2x 2008 (32bit/Standard) domain controllers, and one had a broken NIC. That had to be forcefully demoted. Over the last few weeks I've been migrating everything to 2008R2, but in some places I couldn't do a real migration and simply had to recreate the configuration. Just about everything works but I have a really bizarre network sharing issue.

Domain Controllers:, - Shares can be browsed by IP or hostname.
NAS, Old windows server - Shares can be browsed by hostname or FQDN, but NOT IP.
Windows servers which has local user auth- Shares can be browsed by hostname or IP.

I will go through an example of this below:

"ping NAS" returns "reply from"
"nslookup" returns "nas.local.domain"
"net use t: \\nas.local.domain\share" returns "The command completed successfully" (deleted after)
"net use t: \\\share" returns "System error 233 has occurred. No process is on the other end of the pipe."

At first I thought this was specific to the NAS, but I've since learned that all older windows shares have this problem. New shares created under Vista and old shares that allowed local user authentication seem to work. New folders created on the NAS do not work either.

There is no firewall between devices suffering this issue. No windows firewalls enabled. I cannot at present use packet sniffers or port scanners. Ideas? Questions?
Who is Participating?
arunexpConnect With a Mentor Commented:
You could try changing the client authentication level to normal NTLM and NTLM..this can be done form registry..
we had similar issues when we rolled out w7.. we put packet sniffer and identified it as NAS issue and NAS vendor suggested code upgrade..
BSAFHAuthor Commented:
Unfortunately my working environment requires lots of security. I will see if I can free up a host for testing. Keep in mind, this doesn't just apply to the NAS. It also applies to Windows server hosts (2003, 2008). They're able to browse to their own IP, but other computers cant connect unless using the hostname.
BSAFHAuthor Commented:
I have new information, although it is a little late.
It turns out that each of the windows shares had a slightly different issue, most of them are taken care of. As it stands, only the NAS and 1 Windows Server host cannot be reached. Different reasons.

The NAS will work if I reset it to factory defaults (No AD) but stops immediately after joining the domain. I have therefore opened a case with the NAS vendor as this is likely an issue with their firmware. After doing a tcpdump of the communications with the NAS it looks like its running a linux kernel and samba for sharing.

The last windows host to have a problem, when I trace it it sets up an SMB session with dialect 2.002. The only descriptive packets I see are (poor formatting, copying from handwritten notes): Error Code 412 Status fs driver required ioctl, nt status system error code 34, status access denied tree connect. http response http 1.1 status not found url:/c$. nt status system error 13, status invalid parameter query information, nt status system system error code 94 status_no_logon_servers session setup. 22 status more processing required.

I'm ok with just blaming the nas vendor for that device, but the windows issue I should still be able to fix. It is running Windows Server 2008 Standard.
BSAFHAuthor Commented:
Kerberos can't authenticate against IP, something to do with SPNs require a hostname. NTLMv2 apparently not supported in later versions of Samba or something, lots of NAS vendors use Samba. I haven't figured out yet why my 2008 box can't auth with my 2008r2 but it is probably something similar.
BSAFHAuthor Commented:
LM Compat has 5 levels. 2008R2 defaults to level 4 (NTLMv2 response only). Apparently a lot of NAS boxes use Samba, which has some sort of issue with newer versions of auth (ntlm2, kerberos). My NAS vendor recommended I swap to LM/NTLM send. Not going to happen, but that certainly makes it seem like that it what it is.

I read something about kerberos not being able to auth things on IP, it has to assign an SPN and it can't do that to an IP. My level is too low to get it all. I'm just writing this comment to condense some of my google searches into 1 result for future searchers.

You can modify your policy in secpol or group policy- local policies, security, network settings - network security: LAN Manager Authentication Level.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.