3

One of the computers in my office recently lost the ability to connect to a network share running on one of our servers. "Nothing changed" (don't we all just love that phrase) as far as I can tell; the secretary using it powered it off before going on vacation and powered it on upon returning. Here is the setup:

  • Server: Windows Server 2000
  • Client: Windows 8.1 (Personal/Home edition)
  • Client and Server are both in the same Workgroup, on the same network, and subnet.
  • Client is trying to access a shared folder on the Server but cannot.
  • Server can access shared folders on the Client.
  • Client can ping the Server and RDP successfully.
  • Client's credentials are valid and exist on both it and the Server.
  • Client's account has permissions to the shared folder on the Server.
  • There are other computers on the network that are set up the same way and can access the shared folder on the Server without issue.

Basically, when the Client attempts to access the shared folder on the Server, I am prompted for credentials. No credential combination works, even ones which I know work (by trying them in RDP). The best error message I receive is "The specified Network Credential is invalid."

Things I've tried:

  • Clear the Windows Credential cache.
  • Leave and re-enter the Workgroup.
  • Use different shared folders.
  • Authenticate with different user accounts.
  • Reboot both machines.

Questions I've read:

Things I would love to do, but aren't options right now:

  • Setup a domain.
  • Upgrade from Server 2000.
  • Upgrade to Business/Enterprise Windows for the Client.

Any thoughts? I've dealt with weird issues like this before which always turn out to be some cryptic setting in Windows that unexpectedly flipped one way or the other. My searches thus far haven't turned anything up that seems to fit my situation.

Community
  • 1
jtlovetteiii
  • 131
  • I would check if you can lower the LM hash usage in the Windows 8 first – yagmoth555 Jan 05 '17 at 02:23
  • Client's credentials are valid and exist on both it and the Server - That isn't possible in a Workgroup. Client's account has permissions to the shared folder on the Server - That also isn't possible in a Workgroup. Leave and re-enter the Workgroup - There's no centralized user account database in a Workgroup so that was kind of a pointless thing to do. Can you give us details on exactly what you mean by the statements I highlighted? – joeqwerty Jan 05 '17 at 02:27
  • Have you tried this style of username?: <Computername>\<username>. E.g. elliot-cloud\mdt-user or another example desktop\owner. Can you also tell me the results of net use as both administrator and local user? (I have had this kinda trouble in the past due to a bad password that was in use and not changing).Specifically, this might be handy:http://serverfault.com/a/491755/216286 – Elliot Huffman Jan 05 '17 at 02:53
  • @joeqwerty - By "client's credentials...exist on both...", I mean that there is a user account with the same name and password on both machines. Of course there isn't any sort of real link between the two; the previous admin just set it up that way so users wouldn't have to remember a separate account when mapping a drive/accessing a shared folder. "Client's account has permissions..." is referring to the same thing. When I attempt to access the shared folder on the Server from the Client, I am presented with a Windows login prompt, at which I type "ServerName\UserAcct" and a valid password. – jtlovetteiii Jan 08 '17 at 04:52
  • @ElliotLabs - Yes, when I attempt to access the share, I am presented with a Windows login prompt. Since we don't have a domain, I enter "ServerName\Username" and the password for that account on the Server. I have verified (by logging in with RDP) that the credentials are valid for logon, and I have also verified that the account has permissions to the shared folder. In an act of desperation, I even tried "ClientComputerName\Username", but to no avail. I haven't run "net use" yet; I'll execute it and see what it gives me. – jtlovetteiii Jan 08 '17 at 04:56

1 Answers1

0

Turns out it was one of those things that I should have checked before doing anything else. I did a little more digging, and discovered that the server's clock time was 30 minutes fast. Correcting the clock on the server caused the problem to immediately disappear. I'm not sure how the clock became skewed; my only theory is that power losses over a period of time could have contributed to incremental offsets that eventually exceeded the skew tolerance allowed by the credential negotiation system.

jtlovetteiii
  • 131