Windows not passing credentials when accessing share

active-directorynetwork-sharewindows-server-2003

My company is using a domain environment with Windows 2003 servers. All is great, except for one fussy laptop. Any network-related activity between it and domain servers is slow. Internet activity is fast on the other hand. Logging in to the domain on this particular machine takes around 10 minutes, no exaggeration, even if the roaming profile is already cached on the machine. When trying to access shares that this account (and everyone else in the domain) has access to, it prompts for a password rather than sending the credentials in the background. Even when the credentials are typed in manually, they are still not accepted and the login dialog comes back up. This machine refuses to map drives automatically upon loging as well via our login script, which works fine on over 800 other machines and users. There is nothing fancy in the script, just a few net use statements.

Now for the weird part….

When logging in on other user accounts on this machine, all drives map fine. When logging in as this particular user on another machine, all the drives map as expected and it does not ask for credentials when accessing shares. It is just the combination of this machine and account that don't cooperate. We thought it was the hardware at first, and had the system board replaced (which solved issues with intermittent connection problems) but the issue of the network drives is still apparent and credentials are not being passed correctly or something odd. I have already tried recreating this user's Windows profile to no avail.

Anyone ever encounter anything similar? And how did you fare?

Best Answer

When troubleshooting similar issues, I have found that the best solution is to triage using Wireshark to make packet traces. You need to figure out what is actually going on when the machines communicate. Mirror a port on your switch and run Wireshark three times -- twice on this machine with different users and then once on the same mirrored port using another machine that does work. Look for periods where traffic between the server and client stops for long periods, and figure out which client is waiting and which is not responding. Compare the three traces and see the differences in all communication. Somewhere in there you will find a clue that will show which continent the problem is actually on, if not the street address. Good luck!

Related Topic