'The'account is not authorized to login from this station' error while trying to acccess network share

Question

Clients are getting this error when trying to access network shares on one of our 2008 R2 servers:

The account is not authorized to login from this station.

The problem started a few weeks ago. It is intermittent on a per-client basis and may last for hours or days. The problem does not affect all clients at once.

For example, this morning one client was working and is now not; another client was not working earlier today and now is working. I've seen the issue with both Windows 7 Pro clients and other Windows Server 2008 R2 boxes trying to connects as client to the affected server's shares.

I've tried connecting to the C$ admin share and it does the same thing:

The only search hits I'm getting from the Internet and Microsoft are referencing issues with W2K. There is nothing of relevant interest in event logs on either the server or the clients. What should I try next?

Edit to provide requested information:

This is only affecting one server. We have two other servers in our domain that provide network shares. Shares on those servers are rock-solid 24x7. No access issues whatsoever.

ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : HOSTHV02
   Primary Dns Suffix  . . . . . . . : dc.XXXXXXXXXXX.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : dc.XXXXXXXXXXX.com

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
   Physical Address. . . . . . . . . : 90-B1-1C-17-06-DE
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::d5b:157:2c8a:99a4%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.4.32(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.4.1
   DHCPv6 IAID . . . . . . . . . . . : 244363548
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-76-57-7E-90-B1-1C-17-06-DE

   DNS Servers . . . . . . . . . . . : 192.168.4.16
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{54A6F175-C7D4-4C3E-BCA8-2F4DF4F4CB4D}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Edit

This is doesn't seem to be caused by mismatched signing policies. The problem continues to "randomly" affect client computers. For example, this week my workstation could not access the shares one day, could the next, and then could not again the following day.

Solution 1

Bad DNS Records

Here's our resolution for this particular situation:

Our DNS server had two DNS A records for the problematic server. One record had the correct IP address and one had an a different address. Once I deleted the bad record, this issue went away. The bad record had a timestamp from around the time this issue started. At this point, I am not sure how the record got there, but I believe it was from a dynamic update.

I am now in the process of setting up scavenging on our DNS servers.

Solution 2

As all the Windows 2000-related articles would have told you, had you read them, this error occurs when the client and server has conflicting SMB Signing policies configured.

Namely, the server tries to enforce SMB Signing but the client either refuses or are unable to negotiate SMB Signing with the server

These settings can be defined using either Local Group Policy (gpedit.msc) or Group Policy if you use Active Directory.

^ These are probably the droids you're looking for

Comments

[kralyk]

It's only happening on that 1 2008 R2 server? Other servers with shares are accessible 24/7? Can you edit your question and post the full details of an ipconfig /all of the server in question as well as a gpresult /SCOPE COMPUTER /v

[poke]

@TheCleaner: Updated my answer. Its only this one server. Other shares on other servers are fine. The output of gpresult is too long to post. Is there a particular section you are looking for?

[kralyk]

The gpresult was to check for any kind of GP that would be affecting the server different from the others. If you are confident that they all get the same policies and that the issues in the answers below aren't what's going on, we can keep digging. Also, you said you were trying to connect to C$, what happens if you open compmgmt.msc and right click and try to remote administer that server? Does it work with your credentials or no?

[poke]

@TheCleaner. I can connect via the Computer Management snap-in and view various items (Services, Open Files/Sessions, etc).

[poke]

This issue is interment. How would conflicting signing policies be interment? It seems like it would either work or not work all the time. Right now, the problem seems to move around among clients connecting to this one server.

[joeqwerty]

@poke - I agree that it seems like the problem wouldn't be intermittent if this was the cause. I do think it would be wise to check the settings mentioned in the answer Mathias provided though, if nothing more than to rule it out.

[poke]

@joeqwerty: Of the four policies highlighted in the screen shot, only Microsoft network client: Digitally sign communications (if server agrees) is Enabled. The other three are disabled. These settings are the same on the server and the client.