Connecting to Network share attempts to connect via http
When connecting from my XP machine to a network share on another XP machine (both Pro-SP3), I never get prompted to enter the username & password. After 15+ minutes I finally get the dialog prompting me for a username and password.
Yes, I have disabled Windows Firewall & Anti-Virus. I've also set the NoRecentDocsNetHood registry flag so My Network Places doesn't cache all the remote shares I visit.
Connecting to both XP machines using smbclient on a FreeBSD machine is instantaneous.
I dug out Wireshark to see what is actually being sent over the network and to my surprise I saw that all traffic between the two machines was TCP: not a UDP packet to be seen. Also, I saw that my machine was attempting to connect using the following ports: 80, 139, 445.
I can understand 139 & 445, but I can't for the life of me understand why it's attempting to connect via HTTP.
From Wireshark I've seen that it attempts the following sequence:
1). Ping remote host (gets a reply)
2). Connect via TCP 445
3). SMB protocol negatiation & attempt to login with current user
4). Get STATUS_LOGIN_FAILURE (my current user isn't accepted)
5). Steps 2-4 repeated another 2 times
6). Attempt to connect to TCP 80 for the next 3 minutes (fails as it's not open) WTF?
7). Goto 1
Any suggestions?
John
Yes, I have disabled Windows Firewall & Anti-Virus. I've also set the NoRecentDocsNetHood registry flag so My Network Places doesn't cache all the remote shares I visit.
Connecting to both XP machines using smbclient on a FreeBSD machine is instantaneous.
I dug out Wireshark to see what is actually being sent over the network and to my surprise I saw that all traffic between the two machines was TCP: not a UDP packet to be seen. Also, I saw that my machine was attempting to connect using the following ports: 80, 139, 445.
I can understand 139 & 445, but I can't for the life of me understand why it's attempting to connect via HTTP.
From Wireshark I've seen that it attempts the following sequence:
1). Ping remote host (gets a reply)
2). Connect via TCP 445
3). SMB protocol negatiation & attempt to login with current user
4). Get STATUS_LOGIN_FAILURE (my current user isn't accepted)
5). Steps 2-4 repeated another 2 times
6). Attempt to connect to TCP 80 for the next 3 minutes (fails as it's not open) WTF?
7). Goto 1
Any suggestions?
John
No clue about the port 80 attempt . . . after all, it is Windows. What do you expect?
Do you have log in prompts normally on the XP machines? I had a similar experience until I actually set up logins for my XP boxes.
Download apache or sambar and bring it up on the "called" machine and see what happens when the calling machine starts sending tcp connects to port 80. It may be that the calling box is trying some sort of proxy login.
Good luck,
SteveJ
Do you have log in prompts normally on the XP machines? I had a similar experience until I actually set up logins for my XP boxes.
Download apache or sambar and bring it up on the "called" machine and see what happens when the calling machine starts sending tcp connects to port 80. It may be that the calling box is trying some sort of proxy login.
Good luck,
SteveJ
ASKER
@ChiefIT
I'm using the Run dialog, however typing a network share URN in the run dialog, IE & Explorer all have the same effect, as they are in effect doing the same thing:
Typing \\<Machine>\<Share> into a Internet Explorer window will turn it into a Windows Explorer window.
However, I did forgot to add that when I use the net use command, the connection is made instantaneous:
net use \\<Machine>\<Share> /User:<Username>
Once I've done this, opening the share from the run dialog is then instantaneous. Quite clearly executing the network share URN uses a different mechanism from net use to connect.
@SteveJ
I've always waited for the login prompt, and just used the machines administrator account (I'm usually connecting the default shares). Yes, adding myself as a user to the remote machine works, as does adding a user in the administrators group from the remote machine as a user on my machine. However I'd prefer to avoid having to do either of the above. What's annoying me about this issue is that similar machines aren't experiencing the same issue, pointing to a configuration issue.
Nice idea about having something listen on Port 80 on the remote machine. I'm going to knock up a quick app which will write everything to a log file.
I'm using the Run dialog, however typing a network share URN in the run dialog, IE & Explorer all have the same effect, as they are in effect doing the same thing:
Typing \\<Machine>\<Share> into a Internet Explorer window will turn it into a Windows Explorer window.
However, I did forgot to add that when I use the net use command, the connection is made instantaneous:
net use \\<Machine>\<Share> /User:<Username>
Once I've done this, opening the share from the run dialog is then instantaneous. Quite clearly executing the network share URN uses a different mechanism from net use to connect.
@SteveJ
I've always waited for the login prompt, and just used the machines administrator account (I'm usually connecting the default shares). Yes, adding myself as a user to the remote machine works, as does adding a user in the administrators group from the remote machine as a user on my machine. However I'd prefer to avoid having to do either of the above. What's annoying me about this issue is that similar machines aren't experiencing the same issue, pointing to a configuration issue.
Nice idea about having something listen on Port 80 on the remote machine. I'm going to knock up a quick app which will write everything to a log file.
It appears like you are having a problem authenticating. But, that doesn't make sense either, because you would have long logon times, or timed out logon times.
Maybe the clients are seeing the wrong Domain master browser.
Check "My Network Places" to see if there is a full list of computers or a partial list or no list at all. Also see if there is any delay. Try mapping a drive from my network places.
I think you are in the right zone by checking on Netbios. Sounds like netbios translation is hokey.
Maybe the clients are seeing the wrong Domain master browser.
Check "My Network Places" to see if there is a full list of computers or a partial list or no list at all. Also see if there is any delay. Try mapping a drive from my network places.
I think you are in the right zone by checking on Netbios. Sounds like netbios translation is hokey.
ASKER
Well, my port listener worked a treat, turns out the my machine was sending WebDav OPTION requests to the remote machine. A quick google for the UA gave me this MS knowledge base:
http://support.microsoft.com/kb/832161
Disabling the WebClient service stopped the HTTP requests, but it turns out that they weren't the cause but a symptom.
Going back into Wireshark, I noticed that after the 1st authenticate failed, further requests were being sent out using a different IP (that of my VirtualBox virtual interface). As the source IP was incorrect, the packets weren't being sent back to me (actually my firewall was stopping the from escaping to the WAN). Disabling the VirtualBox interface stopped all this behaviour.
Now I just have to figure out why the packets are being sent from the wrong address, and if this is a known VirtualBox issue. It's also a bit strange that the VirtualBox interface doesn't effect net use (or any other protocols). Hopefully it could just be solved by changing the VirtualBox IP (thought the current one isn't even in my subnet).
http://support.microsoft.com/kb/832161
Disabling the WebClient service stopped the HTTP requests, but it turns out that they weren't the cause but a symptom.
Going back into Wireshark, I noticed that after the 1st authenticate failed, further requests were being sent out using a different IP (that of my VirtualBox virtual interface). As the source IP was incorrect, the packets weren't being sent back to me (actually my firewall was stopping the from escaping to the WAN). Disabling the VirtualBox interface stopped all this behaviour.
Now I just have to figure out why the packets are being sent from the wrong address, and if this is a known VirtualBox issue. It's also a bit strange that the VirtualBox interface doesn't effect net use (or any other protocols). Hopefully it could just be solved by changing the VirtualBox IP (thought the current one isn't even in my subnet).
Glad you figured out it was WebDav for the port 80.. That's a standard windows thing to try, but as you note, it shouldnt be getting to that point..
You dont mention if these machines are in a domain, but since they're PRO version and the SAMBA worked, I'm going to take a stab that this could be it...
XP will want to do Kerberos authentication which encodes the current time as part of the encrypted password. This way, if someone tries to replay a packet later, it can be detected as a hack attempt.. SAMBA is going to use NTLM authentication, which does not do this.
Because your Samba worked, but the XP to XP did not, I'm thinking that the times on the workstations are not synchronized... Dont forget to check the timezone and date too...
If that doesn't help, let us know what's in the event viewed..
-Steve
You dont mention if these machines are in a domain, but since they're PRO version and the SAMBA worked, I'm going to take a stab that this could be it...
XP will want to do Kerberos authentication which encodes the current time as part of the encrypted password. This way, if someone tries to replay a packet later, it can be detected as a hack attempt.. SAMBA is going to use NTLM authentication, which does not do this.
Because your Samba worked, but the XP to XP did not, I'm thinking that the times on the workstations are not synchronized... Dont forget to check the timezone and date too...
If that doesn't help, let us know what's in the event viewed..
-Steve
It appears like you also have Netbios disabled.
Netbios over TCP/IP, (used for file shares) uses these ports:
137, 138, 139
Simultaneously, it will use netbios over SMB, on these ports:
139 and 445.
I don't see the netbios over TCP/IP going out, but I do see the netbios over SMB. So, I see this as a little weird. Are we potentially looking at a multihomed DC with netbios bound to two nics.
To discover your netbios redirection go to the command prompt and type:
Net config redir
the 000000000000 line will be your netbios over SMB
the MAC address will be netbios over TCP/IP.
I call these the old school way and the new school way. But, they both happen at the same time. You should see packets on all of these ports:
137, 138, 139 and 445.
Why is netbios over TCP not working while netbios over SMB is???
Netbios over TCP/IP, (used for file shares) uses these ports:
137, 138, 139
Simultaneously, it will use netbios over SMB, on these ports:
139 and 445.
I don't see the netbios over TCP/IP going out, but I do see the netbios over SMB. So, I see this as a little weird. Are we potentially looking at a multihomed DC with netbios bound to two nics.
To discover your netbios redirection go to the command prompt and type:
Net config redir
the 000000000000 line will be your netbios over SMB
the MAC address will be netbios over TCP/IP.
I call these the old school way and the new school way. But, they both happen at the same time. You should see packets on all of these ports:
137, 138, 139 and 445.
Why is netbios over TCP not working while netbios over SMB is???
ASKER
Sorry about the delay getting back, had a things a tad more important than this issue. After a reboot, I've found that the issue has returned, even though the virtual interface has been disabled. So it turns out that it wasn't the root of the problem. bah!
@172pilotSteve:
Machines are part of a bog-standard workgroup, but I've set them all up to query a local timeserver so the times should all be synced.
@ChiefIT:
NetBios is (should) be enabled. Running nmap, I see that TCP ports 139 & 445 are open on all the machines. I never see any packets on ports 137 or 138.
I've disable the virtual interface, so my NIC should no longer be multihomed.
Aha, this is starting to take the mickey. On a whim, I've just disabled the WebClient service again (actually it appeared to timeout while stopping the service) and everything's fine now. I'm going to do a quick reboot with the WebClient service disabled fixes this issue.
I'm beginning to feel like something's a bit screwed up on this machine.
@172pilotSteve:
Machines are part of a bog-standard workgroup, but I've set them all up to query a local timeserver so the times should all be synced.
@ChiefIT:
NetBios is (should) be enabled. Running nmap, I see that TCP ports 139 & 445 are open on all the machines. I never see any packets on ports 137 or 138.
I've disable the virtual interface, so my NIC should no longer be multihomed.
Aha, this is starting to take the mickey. On a whim, I've just disabled the WebClient service again (actually it appeared to timeout while stopping the service) and everything's fine now. I'm going to do a quick reboot with the WebClient service disabled fixes this issue.
I'm beginning to feel like something's a bit screwed up on this machine.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Well, Microsoft wrote a couple articles about this:
This one explains exactly what you are looking at.
http://support.microsoft.com/kb/832161
Another explains that WebClient is disabled by default and also can be exploited as a security hole.
http://www.microsoft.com/technet/security/Bulletin/MS05-028.mspx
You might keep webclient disabled, monitor it for being re-enabled, and also scan your servers for a worm or some sort of remote execution. An AV scan with the latest definitions should suffice.
Well done in finding the culprite.
This one explains exactly what you are looking at.
http://support.microsoft.com/kb/832161
Another explains that WebClient is disabled by default and also can be exploited as a security hole.
http://www.microsoft.com/technet/security/Bulletin/MS05-028.mspx
You might keep webclient disabled, monitor it for being re-enabled, and also scan your servers for a worm or some sort of remote execution. An AV scan with the latest definitions should suffice.
Well done in finding the culprite.
Windows explorer will default to netbios, internet explorer will default to looking for an internet site.
right click "My Computer" icon and select explore. NOW, try and connect to the share.