Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
|Type: Failure Audit|
Reason: Unknown user name or bad password.
User Name: <user name>
Domain: <domain name>
Logon Type: <logon type>
Logon Process: <process name>
Authentication Package: <package name>
Workstation Name: <computer name>
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is an authentication protocol?
This event record indicates an attempt to log on using an unknown user account or a valid user account but with an incorrect password. An unexpected increase in the number of these audits could represent an attempt by someone to find user accounts and passwords (such as a "dictionary" attack, in which a list of words is used by a program to attempt entry).
Common causes for invalid logon events:
- Forgotten passwords, someone is entering the wrong password.
- An unauthorized individual is trying to gain access to the network.
- There is a persistent network connection with an invalid password.
- There is a service using a user account with an invalid password.
- Trust relationship has been broken.
ME290706 says that remote automatic logon operation to a computer that is running Terminal Services with a long user name or password is not supported. If this is attempted, the logon fails and this event gets recorded.
See the link to Windows Logon Types for information about various codes that may appear there.
See the link to Windows Authentication Packages for information about the <authentication package> field.
This event has also been observed on IIS web servers that have NTLM authentication enabled. If an anonymous user connects to the web server through MS Internet Explorer, the browser will try first to authenticate the user using the login credentials of that user. Since there is no such user configured in the security database of the web server, the authentication attempts fails and the browser will then attempt to connect anonymously.
I was recently asked to diagnose why the Event Viewer on a dedicated Win2003 Web Server was showing hacker login attempts via Windows Authentication.
The Security log was littered with hundreds of the following events:
Event ID: 529
Type: Failure Audit
Reason: Unknown user name or bad password
User Name: a seemingly dictionary-style list of common administrator values
Logon Type: 8
Logon Process: IIS <<-- important to note, in comparison to a Remote Desktop connection which shows as Logon Process: User32, Logon Type: 10.
Moreover, each attempt to authenticate was causing the server to launch an instance of WinLogon.exe and CSrss.exe. This quickly rendered the server unresponsive, while its CPU peaks during processing of the in-bulk attempts to gain access.
In summary, ensure that websites defined in IIS do not have "Integrated Windows authentication" enabled, unless the server is on an intranet/domain where such credentials would be utilized to access resources.
Related to Anonymous' post about the screensaver, if the Windows XP Welcome screensaver is enabled, event IDs 529 and 680 are written to the security log because the welcome screen tries to logon to each account listed on the Welcome screen to determine if a password is enabled for that account. ME305822 says that this problem was resolved with XP SP 1, but I have XP SP3 and it still occurs.
See ME947861 for a hotfix applicable to Microsoft Windows Server 2003.
This error can occur if the password for the user account that is used for anonymous access in IIS is not synchronized with the password for the user account in Active Directory, or with the password for the user account in Local Users and Groups. See ME909887 to solve this problem.
See "Sophos Support Article ID: 14567" if you have Sophos Anti-Virus Small Business Edition installed.
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.
I have noticed this error on two separate SBS2003 domains with WinXP SP2 clients. In both cases, the workstations had not been rebooted for over a month. Resetting the computer account, either through AD or rejoining the computer to the domain using the same account through the Network Identification Wizard, has resolved the problem.
This error was seen on a Windows 2003 standard server running IIS 6.0 when attempting to browse to a new website on the server. The new website was asking for a Windows user ID and password. The error in the event log appeared before a user/password was given or Cancel was clicked.
The anonymous authentication user (IUSR_somename) was already in use by another website on the server, so it did not make sense that it was not working. MS Article ME909887 listed possible causes, one of which was "The wrong user name or password is specified in the IIS Metabase”. The IIS metabase is (normally) located at C:\Windows\System32\inetsrv\MetaBase.xml. I compared the AnonymousUserPass string of the existing (working) site and the new (not working) site and they were different.
To modify the MetaBase.xml file the IIS services must be stopped or the "Enable Direct Metabase Edit" option must be enabled in IIS Manager/<server name>/Properties. First, make a copy of the MetaBase.xml file (ex: MetaBase.xml.old), then edit it. Copy the AnonymousUserPass string from the working site to the non-working site. Save the changes and start the IIS services.
We have a workgroup and the users are mapped to our SBS2003 SP2 server so they can authenticate to get their email from Exchange. One user (using Windows XP SP2) who was mapped could get his email but could not browse the mapped drive of the server. The problem turned out to be the following. If you go to "User Accounts" in the Control Panel then click on the user name and then go to "Manage my network passwords" make sure the mapped drive the user is connected to, begins with the computer name of the server followed with his user name (for example: \\dell799\username). Putting in the correct username fixed the problem for us.
See ME328720 for a hotfix applicable to Microsoft Internet Information Services 5.0.
See ME890477 for a hotfix applicable to Microsoft Windows Server 2003.
See ME824209 on how to use the EventCombMT utility to search the event logs of multiple computers for account lockouts.
Other Microsoft articles with information related to this event: ME159221, ME159792, ME159969, ME299352, and ME326985.
As per Microsoft: "This event record indicates an attempt to log on using an unknown user account or a valid user account but with an incorrect password. An unexpected increase in the number of these audits could represent an attempt by someone to find user accounts and passwords (such as a "dictionary" attack, in which a list of words is used by a program to attempt entry)". See MSW2KDB for more details on this issue.
See "Trend Micro Support Solution ID: 1031378" if you tried to run the Trend Micro Vulnerability Scanner (TMVS).
Joseph C. Chiaro
From a newsgroup post: "When a password is changed on the machine hosting the IIS server, the changes do not always propagate through all of the web applications, especially if they are COM-based or ASP-classic applications. Running synciwam.vbs (located in my case in c:\Inetpub\AdminScripts\) may solve the problem". I am running IIS 5.0 on Windows XP, with mostly ASP.Net applications. I was getting this error with one of the few ASP classic apps I am still maintaining after changing the password on the hosting box. Running this script solved the problem.
We were getting Event Id 529 logged after a reboot of our Windows Server 2003 Domain Controller. The information in the 529 event contained the reason "Unknown user name or bad password", a logon type of 3, and the logon process and authentication process set to Kerberos. One of the knock effects of this error was that Windows XP clients could not update their Group Policy; these clients had Event Id 1053 in the Application event log “Windows cannot determine the computer or user name. (Access is denied.). Group Policy processing aborted".
We had the following group policy enabled in the Security settings "Audit: Shut down system immediately if unable to log security alerts". The GPO settings for the security event log were set to "Do not overwrite events (clear log manually)". When the DC was rebooted, Windows Server 2003 was setting the Crash On Audit Fail registry key (HKLM\System\CurrentControlSet\Control\Lsa\crashonauditfail) to 2. Note that no Crash On Audit Fail blue screen appeared and the security event log was not full so there was no related message shown. We therefore had no indication that the crash on audit fail registry key had been set to 2. With this registry key set to 2 only administrators can log on to the DC. Setting the value of this key to 0, changing the GPO's to disable "Audit: Shut down system immediately if unable to log security alerts", and changing the retention method of the security event log to "Overwrite events as needed" solved the problem.
When you want to use DameWare Client for remote control on a Windows XP Professional computer, just disable Simple File and Print Sharing. You can find this in Windows Explorer -> Tools -> Folder Options -> tab View. Scroll down and uncheck simple file sharing.
This error occurs also when a DOS/Windows 9x or Mac OS X/Linux client makes a drive mapping to a Windows 2003 Server share in a Windows 2003 Domain. To resolve this problem disable on the Windows 2003 domain controller the Microsoft network server: Digitally sign communications (always) (Administrative Tools->Domain Controller Security Policy) in the subgroup Security Options from the group Local Policies.
This event may appear in the Exchange server event log if the SMTP server component is configured to attempt to authenticate remote SMTP server using NTLM authentication. If the remote server is not able to provide a valid user id/password, this event will be recorded. Verify the properties of the SMTP server component.
As per ME287639, if a user on a computer that is running Microsoft Windows 95 or Microsoft Windows 98 attempts to log on to a Windows 2000-based domain and is validated by a domain controller that has that user's account locked, but the primary domain controller operations master (also known as flexible single-master operations or FSMO) has the account unlocked, the logon attempt is denied. The problem was fixed by SP3.
This event may show up if the server is configured to accept NTLMv2 only ("LAN Manager Authentication Level" Policy is configured to "Send NTLMv2 response only/refuse LM & NTLM"), and if the (pre-Win2K)client is default configured. By some mysterious reason, the NTLMv2 client package comes with a default setting ensuring that it will never be used (NtLMCompatibilitylevel=0). Configure at least NtLMCompatibilitylevel=1 as described in ME239869.
I've got this message when the logon screen appeared after the screensaver was interrupted by a user, but user does't logon. Then logon screen disappeared after timeout. Remark: the screensaver was protected by password. See ME305822.
The event occurred on Windows XP if the machine environment meets the following criteria:
- The machine is a member of a domain.
- The machine is using a machine local account.
- Logon failure auditing is enabled.
When the user logs off, Windows will write event ID 529 to the log file because the OS incorrectly tries to contact the domain controller (DC), despite the fact that the machine is using a local account. Microsoft currently doesn't provide a fix for this problem, but you can safely ignore this event ID.
ME811082 may address this issue to some extent. See also ME312827.
|Private comment: Subscribers only. See example of private comment|
|Links: Windows Logon Types, Windows Authentication Packages, Windows Logon Processes, Online Analysis of Security Event Log, Sophos Support Article ID: 14567, EventID 1053 from source Userenv, Trend Micro Support Solution ID: 1031378|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (2) - More links...|
Send comments or solutions
- Notify me when updated