Event ID/Source search
Keyword searchExample: Windows cannot unload your registry file
Event ID: 681 Source: Security
|Type: Failure Audit|
The logon to account: <account name>
by: <authentication package>
from workstation: <workstation name>
failed. The error code was: <error code>
|English: Request a translation of the event description in plain English.|
|Concepts to understand:|
What is an authentication protocol?
This event indicates a failed logon attempt. A decimal error code is included in the event (i.e. 3221225578) that translates to the cause of the failure. See ME273499 for what different codes mean.
If the problem is constant lockouts for a particular user, a corrupted profile can be responsible. I used Microsoft's ALTools.exe and Ethereal to discover that on every logon, because of the corrupted profile, the PC was sending several PCNAME\Username logons to the domain controller, instead of DOMAIN\Username. Surprisingly, this was locking out the domain account for that user. Creating a fresh profile for the user resolved the problem.
We saw this occur on several lab machines that share a user account. Someone changed the password on one of the machines while the others were still logged in. When the other machines later tried to access network resources, they were denied and were unable even to write to some local files, print, etc.
See ME922730 and ME933986 for information about this event.
See ME837142 for a hotfix applicable to Microsoft Windows 2000 and Microsoft Windows XP.
See ME824209 on how to use the EventCombMT utility to search the event logs of multiple computers for account lockouts.
As per Microsoft: "The license metering client uses the currently logged on user account to authenticate and connect to the license metering server to copy log files. If that user's account is disabled, locked out, or otherwise invalid, the license metering client attempts hundreds of logon attempts on the license metering server, and this creates very large security log files". See ME287626 to fix this problem.
As per Microsoft: "If you try to open a Web site on a Microsoft Internet Information Services (IIS) Web server by using the FrontPage client while either the IUSR_computer or IWAM_computer account is turned off this event may be logged in your event log. This happens because the IUSR_computer and IWAM_computer accounts must be turned on for IIS to function correctly". See ME321448 for more details.
See "Trend Micro Support Solution ID: 1031378" if you tried to run the Trend Micro Vulnerability Scanner (TMVS).
From a newsgroup post, from a Microsoft Engineer: "Some rules of thumb:
1) Ignore single bad password events. If it only happens once, it's probably not worth investigating.
2) When examining logon failures, go to the workstation that is generating the bad requests and look for something there, particularly a service.
3) Don't assume it's a hacker until you rule out everything else".
From a newsgroup post, from a Microsoft Engineer:
"529 is a failure event (bad username or password) in the "Logon/Logoff" category of audits – it is generated when the creation of a logon session (and token) fails, on the machine where access was attempted.
681 is a failure event (account logon failure) in the "Account Logon" category of audits - it's generated when a security package authenticates your credentials. This occurs on the machine authoritative for the account being used - the local machine in the case of local accounts or a Domain Controller in the case of domain accounts. There is no corresponding logoff event for Account Logon events.
When you log on to a domain, it's typical to see both kinds of events on the DC and the first kind (logon/logoff) on the workstation. The DC generates an account logon event when it validates your credentials. The workstation generates a logon/logoff event when it receives the DC's response and allows you to log on. The DC then generates one or more logon/logoff events as your workstation connects to it to download your login scripts, user profile, etc".
If you lo on to a Win2k Terminal Server via Citrix Metaframe you’ll get this error when you use the ICA Client without providing a domain name. The logon will work but the Server will attempt to log you on locally before asking the AD. Workaround: Enter the domain name in the appropriate field in the ICA client. Should you (as we do) use an UPN name to log on (email@example.com) you might think providing the NT-style "mydomain” is not necessary because the Win2k GINA will gray out the domain name field. However, if you connect via Citrix client you will have to provide it anyway or decide to live with the event log entries. In this particular case, they do not hurt in any way.
You can also get this error when trying to map a file share after disabling NTLM (e.g. from a Security Template). Even though the username and password will work even to log in as an Admin to a Terminal Server, the same credentials will fail when mapping a drive. In your security template, under Local Policies > Security Options, check LAN Manager Authentication Level. Make sure it allows NTLM version 1 and 2 (rejecting regular LM is fine). This can also be a problem for SAMBA, obviously. The giveaway is the credentials working in one situation and not another.
If the user is the IWAM account then this event may be caused by mismatching passwords between the IIS metabase and the user database. See ME297989.
This event may be also caused by IIS Kerberos-related issues. See ME326985.
|Private comment: Subscribers only. See example of private comment|
|Links: ME174074, ME272594, ME273499, ME287626, ME297989, ME321448, ME326985, ME824209, ME837142, ME922730, ME933986, Online Analysis of Security Event Log, Trend Micro Support Solution ID: 1031378|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (1) - More links...|
Send comments or solutions
- Notify me when updated