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?
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)
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:
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.
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