Problem Accessing Shares on Local Machine w/ Hostname Defined in \etc\hosts

[froglander]

Here is the problem. Say I have a Windows XP box with shared folders,
w/ IP address 192.168.1.100. The name of the box is "box1". To access
shares locally, either \\box1 or \\192.168.1.100 work just fine when
typed in the Explorer address bar.

Now, I put an entry "192.168.1.100 box2" in
c:\windows\system32\drivers\etc\hosts. Command "ping box2" shows the
right IP address. However, \\box2 does not work. It connects, pulls
up a login window with title "Connect to box1", but nobody can login
(the login window should not have appeared in the first place).

I remember it worked fine in the past, but at some point after one of
the Windows updates, it stopped working. Searched the knowledge base,
the web, groups, and tried all conceivable fixes, including the obscure
EnableSecuritySignature/RequireSecuritySignature registry settings, but
nothing works.

Please help.

 

[Chuck]

Here is the problem. Say I have a Windows XP box with shared folders,
w/ IP address 192.168.1.100. The name of the box is "box1". To access
shares locally, either \\box1 or \\192.168.1.100 work just fine when
typed in the Explorer address bar.

Now, I put an entry "192.168.1.100 box2" in
c:\windows\system32\drivers\etc\hosts. Command "ping box2" shows the
right IP address. However, \\box2 does not work. It connects, pulls
up a login window with title "Connect to box1", but nobody can login
(the login window should not have appeared in the first place).

I remember it worked fine in the past, but at some point after one of
the Windows updates, it stopped working. Searched the knowledge base,
the web, groups, and tried all conceivable fixes, including the obscure
EnableSecuritySignature/RequireSecuritySignature registry settings, but
nothing works.

Please help.

The ability to access another computer, by either name ("\\box2") or by IP
address ("\\192.168.1.100") is by Server Message Blocks. Traditionally, SMBs
use NetBT (or alternate protocols).
<http://nitecruzr.blogspot.com/2006/04/netbios-over-tcpip.html>
http://nitecruzr.blogspot.com/2006/04/netbios-over-tcpip.html

With Windows XP, you CAN dismiss NetBT, and use SMBs directly hosted. This
causes complications though.
<http://nitecruzr.blogspot.com/2006/07/advanced-windows-networking-using.html>
http://nitecruzr.blogspot.com/2006/07/advanced-windows-networking-using.html

I recommend that you Enable NetBT, and properly configure all firewalls.
<http://nitecruzr.blogspot.com/2005/05/your-personal-firewall-can-either-help.html>
http://nitecruzr.blogspot.com/2005/05/your-personal-firewall-can-either-help.html

You could look at "browstat status", "ipconfig /all", "net config server", and
"net config workstation", from each computer, and diagnose the problem. Read
this article, and linked articles, and follow instructions precisely (download
browstat!):
<http://nitecruzr.blogspot.com/2005/05/troubleshooting-network-neighborhood.html#AskingForHelp>
http://nitecruzr.blogspot.com/2005/05/troubleshooting-network-neighborhood.html#AskingForHelp

 

[froglander]

Chuck,

Thanks for the reply!

It's probably not a NetBT problem or for that matter a problem at the
network layer. I'm trying to access "box1" itself, locally, without
involving other computers. With \\box2, it makes the connection
immediately. It just doesn't allow anybody to login. Most likely it's
a security setting somewhere in the registry causing this problem.

To clarify things:

1. Trying to access a Windows XP box over the network, but locally to
itself (similar to what you would do with "127.0.0.1").
2. Box is named "box1", IP 192.168.1.100. Both \\box1 and
\\192.168.1.100 work fine.
3. Define another name "box2" in \windows\system32\drivers\etc\hosts,
i.e. "192.168.1.100 box2".
4. \\box2 makes the connection, but nobody can login.

A login window pops up (which shouldn't), shows title "Connect to
box1". Notice that it says "box1" even though it's accessed with
\\box2, so it's making the right connection. I tested on a number of
systems. Some showed both the "User name" and "Password" fields.
Others had "User name" field grayed out with "box1\Guest" in it, and
only allowing input in the "Password" field.

 

[froglander]

OK made a small progress.

There is a setting, "Network access: Sharing and security model for
local accounts", under Administrative Tools -> Local Security Policy ->
Local Policies -> Security Options. Change it to "Classic" instead of
"Guest only" and the login window "User name" field allows input.

However, it still does not accept any login username/password. (Again,
the login window shouldn't have been there in the first place.)

 

[Chuck]

OK made a small progress.

There is a setting, "Network access: Sharing and security model for
local accounts", under Administrative Tools -> Local Security Policy ->
Local Policies -> Security Options. Change it to "Classic" instead of
"Guest only" and the login window "User name" field allows input.

However, it still does not accept any login username/password. (Again,
the login window shouldn't have been there in the first place.)

You changed from Simple to Advanced File Sharing. For either to work, though,
you need an account on the other end that's properly activated for network
access. Guest (AFS or SFS) or non-Guest (AFS only), any account has to be
properly activated. Please read my article, and follow the links.
<http://nitecruzr.blogspot.com/2005/06/file-sharing-under-windows-xp.html#Help>
http://nitecruzr.blogspot.com/2005/06/file-sharing-under-windows-xp.html#Help

You could, of course, have a firewall problem. Firewalls, when overlooked or
misconfigured, can cause your problem.
<http://nitecruzr.blogspot.com/2005/05/your-personal-firewall-can-either-help.html>
http://nitecruzr.blogspot.com/2005/05/your-personal-firewall-can-either-help.html

 

[froglander]

Enabled logon audit and here is what's in the event log:

------------------------------------------------------------
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 537
Date: 7/21/2006
Time: 1:41:31 PM
User: NT AUTHORITY\SYSTEM
Computer: box1
Description:
Logon Failure:
Reason: An error occurred during logon
User Name: user
Domain: box1
Logon Type: 3
Logon Process:
Authentication Package: NTLM
Workstation Name: box1
Status code: 0xC000006D
Substatus code: 0x20

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
------------------------------------------------------------

Event ID 537 is an "unexpected error", which basically means nobody
knows what's going on. Search engines didn't give meaningful results.
At this stage I'd be surprised if anyone has the answer who's not an MS
programmer/engineer.

This is where the proprietary/closed-source nature of MS really sucks.
I've spent countless hours researching/debugging this. Had the source
code been available, it would've probably been figured out by now.

 

[froglander]

you need an account on the other end that's properly activated for network
access. Guest (AFS or SFS) or non-Guest (AFS only), any account has to be
properly activated. Please read my article, and follow the links.

Chuck,

There is no other end. As I mentioned, I am accessing "box1" itself,
locally, even though it's done over the network. It should have used
the current login username and password just as the way it works with
\\box1 or \\192.168.1.100. But unfortunately, it doesn't work with
\\box2. (\\box1 and \\box2 are the same box, both accessed locally, as
described above.)

 

[Chuck]

Chuck,

There is no other end. As I mentioned, I am accessing "box1" itself,
locally, even though it's done over the network. It should have used
the current login username and password just as the way it works with
\\box1 or \\192.168.1.100. But unfortunately, it doesn't work with
\\box2. (\\box1 and \\box2 are the same box, both accessed locally, as
described above.)

If you are accessing a computer thru its IP address, you are involving Windows
Networking, and authentication. No "other end" or "other end", if you want
access, you'll have to authenticate. And you'll be subject to firewall problems
too. Read the articles.

 

[froglander]

I see what you are saying, Chuck. But as I mentioned, I have checked
everything obvious.

Again, I am trying to access a computer itself, locally ("local" to the
computer), even though the access is done through the network layer.
(There are reasons for this but I don't want to introduce unnecessary
complications.)

If you have a Windows XP Pro, 2003 Server, or anything equivalent but
with the latest patch, you can easily try it yourself and see what's
going on.

1. Find the name of the computer, e.g. "box1", and type "\\box1" in the
Explorer address bar. You should see shared resources immediately.

2. Find the IP address of the computer, e.g. "192.168.1.100", and type
"\\192.168.1.100" in the Explorer address bar. Again you should see
shared resources immediately.

3. On the same computer, add line "192.168.1.100 box2" (replace
192.168.1.100 with the computer's own IP address) to the end of the
"c:\windows\system32\drivers\etc\hosts" file, and type "\\box2" in the
Explorer address bar. You should connect immediately and get a login
window which does not work with any username/password. (You might get
an error "can not find \\box2", in which case change network settings
so that it connects. Sometimes simply wait for a moment for the
\etc\hosts change to take effect. No reboot required.)

Apparently, with "\\box2", it is not authenticating correctly with the
current login username/password (or any username/password), as it does
with both "\\box1" and "192.168.1.100". Most likely there is some
security checking going on and it finds that the connection is made
with the correct IP address but "wrong" hostname, so it does something
weird. The problem is quite obvious. I just need to find the
fix/workaround.

Once again, all these are done locally on one computer, without
involving any other computer. (As a matter of fact, if you add the
\etc\hosts line on a second computer and make the "\\box2" connection
*remotely* to the first one, you should be able to login. But as I
said, there is no need to introduce unnecessary variables or
complications to the story.)

 

[froglander]

Found the solution:

http://groups.google.com/group/micr...general/browse_thread/thread/eedce70f1c202dff

To summarize: 2003 SP1 breaks the DisableStrictNameChecking key, which
can be fixed by the DisableLoopbackCheck key.

F***ing stupid. I lost 24+ solid hours and half an inch of hair-line
on this. Long-term solution: switch away from anything Microsoft. (I
know this is a microsoft.public.* group, but WTF...)