Security – Access denied error 3221225578 with file sharing to Windows server

file-sharingSecuritywindows-2000windows-event-log

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)

Best Answer

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.

Related Topic