In my case, I had issues with a user that had synced their Blackberry to her work email account. When her password expired and she made a new one, her phone still tried to use the old password. This was causing event ID 680 to be logged and would eventually lock her AD account. The "workstation" field was left blank in every log entry which is what lead me to check out her phone.
- Error code 0xC0000064
- See ME947861
for a hotfix applicable to Microsoft Windows Server 2003.
See "Dorian Support Article ID: DSC20281" for an article containing information about this event.
for different situations in which this event occurs.
Error code 0xC0000064
- This error code can occur if a server is configured to Require NTLMv2 Session Security and the client either is configured to not use it or is unable to negotiate it (e.g., Altiris DOS network boot stuff).
This event could occur if you try to use certificate authentication with IIS and IIS fails to validate the certificate and falls back on other authentication mechanisms. The most common fallback mechanism is Integrated authentication and therefore this event is generated as the client is normally a web client and not part of the domain. Things to check with client Certificate authentication is that the server trusts the root certificate and that the server can access the Certificate revocation list published by the root certificate. Once the server will be able to authenticate the certificate, it will not attempt to use any other authentication mechanisms.
IIS 6 intranet web site with Integrated Windows Authentication was causing more than a thousand instances of this event per day, even though the site worked. There were no 403 errors in the log files for the site that could be associated with the Security 680 event.
Clients were using Kerberos, which failed and caused the 680 event, then failed over to NTLM with success. I checked the IIS metabase NtAuthenticationProviders and found it was incorrectly set to "NTLM", instead of "Negotiate, NTLM", which corrected the problem.
See the link to “Integrated Windows Authentication“ for more information.
During setup for a Windows 2003 Enterprise server I used TweakUI to auto-logon the Administrator account with its password. I then changed the account name to something different. I changed the auto-logon name and password in TweakUI but did not reboot immediately. This message occurred prior to rebooting but there were no problems after the next reboot.
According to ME326985
, 0xC0000064 means "The specified user does not exist". Apparently, some process I initiated prior to rebooting tried to use the old Administrator name and password and was denied.
- Error code 0xC0000064
- I discovered one of our workstations had somehow managed to add a stored password (under Control Panel -> Users -> Advanced -> Manage Passwords) with the form firstname.lastname@example.org. This created thousands of failure events as the user browsed our intranet. Removing the offending entries stopped the events.
As per MSW2KDB
, a set of credentials was passed to the authentication system on this computer either by a local process or by a remote process or user.
Success or failure is displayed in the message. If this event indicates success, then the credentials presented were valid. The error code is 0x0 for success messages. For failure messages, the user field in the message header displays NT AUTHORITY\SYSTEM, and an NTStatus code is displayed.
If this error includes Error code 0xC000006E
on the WinXP side and if the Win98 side gives a popup with "Error 31" then the problem may be that the user has a blank password and the XP machine’s local security policy has disabled blank password access across the network. Go to Start -> Programs -> Administrative Tools -> Local Security Policy -> Local Policies -> Security Options. Find "Accounts: Limit local account use of blank passwords to console login only" and disable it.
- Error code 0xC000006A
- According to Microsoft Windows XP attempts a limited logon for each account that is displayed on the Welcome screen to determine whether to prompt the user for a password. An attempted logon is logged for each account displayed. To resolve this problem, obtain the latest service pack for Windows XP. To prevent these events from being logged, disable the Welcome screen and use the classic logon screen or turn off auditing of logon events. See ME305822
for additional information about this issue.
From a newsgroup: "It is possible that auto-login was enabled and then the password was changed, resulting in XP going to a login prompt to get a valid username/password."