4

i'm trying to access the shares on a server. The credential box appears, and i enter in a correct username and password, and i get access denied.

The silly thing is that i can Remote Desktop to the server (using the same credentials), and i can check the Security event log for the access denied errors:

Event Type: Failure Audit
Event Source:   Security
Event Category: Account Logon 
Event ID:   681
Date:       3/19/2011
Time:       11:54:39 PM
User:       NT AUTHORITY\SYSTEM
Computer:   STALWART
Description:
The logon to account: Administrator
 by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 from workstation: HARPAX
 failed. The error code was: 3221225578

and

Event Type: Failure Audit
Event Source:   Security
Event Category: Logon/Logoff 
Event ID:   529
Date:       3/19/2011
Time:       11:54:39 PM
User:       NT AUTHORITY\SYSTEM
Computer:   STALWART
Description:
Logon Failure:
    Reason:     Unknown user name or bad password
    User Name:  Administrator
    Domain:     stalwart
    Logon Type: 3
    Logon Process:  NtLmSsp 
    Authentication Package: NTLM
    Workstation Name:   HARPAX

Looking up the error code (3221225578), i get an article on Technet:

Audit Account Logon Events By Randy Franklin Smith

...

Table 1 - Error Codes for Event ID 681

Error Code  Reason for Logon Failure
3221225578  The username is correct, but the password is wrong.

Which would seem to indicate that the username is correct, but the password is wrong.

i've tried the password many times, uppercase, lowercase, on different user accounts, with and without prefixing the username with servername\username.

What gives that i cannot access the server over file sharing, but i can access it over RDP?

enter image description here

Edit: i tried entering random credentials (i.e. username: ramdom), just to make sure i'm trying to connect to the correct server. The event log on the server shows the failed attempt:

Event Type:   Failure Audit
Event Source: Security
Event Category:   Logon/Logoff 
Event ID: 529
Date:     3/20/2011
Time:     8:40:28 AM
User:     NT AUTHORITY\SYSTEM
Computer: STALWART
Description:
Logon Failure:
  Reason:     Unknown user name or bad password
  User Name:  random
  Domain:     HARPAX
  Logon Type: 3
  Logon Process:  NtLmSsp 
  Authentication Package: NTLM
  Workstation Name:   HARPAX

Edit: Trying all possible LAN Manager Authentication Levels (secpol.msc -> Security Settings -> Local Policies -> Security Options -> LAN Manager Authentication Levels):

  • Send LM & NTLM responses: Fails
  • Send LM & NTLM - use NTLMv2 session security if negotiated: Fails
  • Send NTLM response only (default): Fails
  • Send NTLMv2 response only: Fails
  • Send NTLMv2 response only\refuse LM: Fails
  • Send NTMLv2 response only\refuse LM & NTLM: Fails

(Client: Windows 7. Server: Windows 2000 Server)

Ian Boyd
  • 5,131
  • 14
  • 57
  • 79
  • Two years later i'm getting the same problem. i google for "Cannot access Windows 2000 share from Windows 7", and i find a well-written, clear, concise, question, with helpful screenshots showing the exact same problem i'm having. *"Oh wait, i wrote this question. What's the answer? Oh yeah. Yup, 2k server was 45 minutes fast"* ***Very*** unhelpful Microsoft. – Ian Boyd Apr 14 '13 at 16:15

2 Answers2

3

i figured out the problem, it had to do with the clock settings on both machines:

  • Client: 3/20/2011 1:28:17 ᴘᴍ
  • Server: 3/20/2011 1:28:17 ᴘᴍ

To the untrained eye, it appears as though both clocks read the same. There's a limitation of the negiotation protocol which requires that all clocks be within 15 minutes of each other. These clocks differ by an hour. This is because the operating systems involved:

  • Client: Windows 7
  • Server: Windows 2000 Server

And because Windows 2000 Server is no longer supported, its daylight savings start date is no longer valid. So the times on both machines are really:

  • Client: 3/20/2011 1:28:17 ᴘᴍ EDT
  • Server: 3/20/2011 1:28:17 ᴘᴍ EST

That's because the client has (correctly) switched to Daylight Savings Time, while the server is still on Standard Time. This means that the client machine clock is an hour ahead of the server clock - and so the two cannot authenticate.

Normally when the two clocks are more than 15 minutes out of sync, you would get a message warning you of that fact. In this case the clocks are synchronized, so there is no warning.

Summary: 3221225578, Windows 2000, Daylight Savings Time

In the meantime, just to make things work, i've restored to clock to the server to be an hour behind - and i'll let the "natural" DST switchover catch up - and transactions will start happening at the correct time again.

Ian Boyd
  • 5,131
  • 14
  • 57
  • 79
  • Interesting. If you want, you can export HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones from a Windows 7/2007/R2 machine and import it on the Windows 2000 machine. I don't believe this takes effect until the restart though. Some organizations actually make this a GPO. – Greg Askew Mar 21 '11 at 20:43
  • Also useful: grab [TZedit.exe from Microsoft here](http://download.microsoft.com/download/5/8/a/58a208b7-7dc7-4bc7-8357-28e29cdac52f/tzedit.exe), and edit your timezone for the current rules, then restart and ensure your DST is now correct and ensure the clock is correct (if it was previously manually adjusted). More details [here](http://www.spy-hill.net/~myers/help/windows/DST.html). – jeff Mar 25 '12 at 23:16
1

There can be multiple causes for a 3221225578 (0xC000006A) authentication failure code. One is a mismatch with the LMCompatibilityLevel setting. If the server is configured more restrictively than the workstation, this is one of the symptoms.

Also, be careful when testing this. If your workstation is set to a permissive/low value, it's possible that increasing it to a high value could cause it to blue screen on startup (if the dc's are also set to low/permissive value), and you may need to use the Last Known Good start menu option to recover.

The Most Misunderstood Windows Security Setting of All Time
http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • i remember reading that link a year or two ago. i remember it not helping to clear up the confusion back then, either. In my case it really was the clocks. – Ian Boyd Aug 29 '11 at 23:17