Event ID 12294 Source SAM
| Event ID | 12294 |
| Source | SAM |
| Type | Error |
| Description | The SAM database was unable to lockout the account of due to a resource error, such as a hard disk write failure (the specific error code is in the error data). Accounts are locked after a certain number of bad passwords are provided so please consider resetting the password of the account mentioned above. Data: 0000: <error code> |
| English, please! | This information is only available to subscribers. An example of English, please! |
| Comments |
Adrian Grigorof
(Last update 8/7/2006): From a Usenet post: "Think I have sorted this problem, one of our servers has a different Local Administrator password, compared to Domain Administrator, because all services on that server use the local Admin account. I don't know what services require the domain wide account, but setting them the same has fixed all problems." The most common error code found in the data portion of the event is a5 02 00 c0 (that is hex error 0xc00002a5 - DS_BUSY). DaViD-Kaman (Last update 10/7/2009): I have found this event was generated by a Terminal Server/RDP session to a Windows 2000 server logged in as a local admin. This session was left logged in/active. I think there was a Windows Explorer window opened which was used to access the Server (2003) with the 12294 error event. Access to that server required AUTHENTICATING as Domain Administrator since I was logged in as Local Admin on the 2000 server. Potentially the automatic refresh of the Explorer window on the 2000 server caused a failed login and in its turn producing the 12294 error. The Security (Audit) Events on the 2003 Server reflected the failed login from the 2000 server. This pointed me to the 2000 Server. Logged out the RDP Session and it was all over. No more 12294 error events. Anonymous (Last update 1/12/2009): Log onto the affected Domain Controller and check failure audits in Security log. In my case I found eight PCs affecting our DC. I forced shutdown them and the attacks stopped. The PCs were taken off domain and reinstalled to ensure no virusses. All was fine after that. K. Olson (Last update 8/27/2007): In our case, these errors occurred because of an FTP dictionary attack in which the attacker was attempting to logon to our FTP servers as Administrator. For each one of these entries on our Domain Controller there was a corresponding entry in our Microsoft FTP log files. Ionut Marin (Last update 1/2/2005): This problem can be caused by the W32.Randex.F worm. See M887433 for details on this issue. See M824209 on how to use the EventCombMT utility to search the event logs of multiple computers for account lockouts. From a newsgroup post: "The administrator account is not subject to lockout. You need to examine the client machine(s) where the bad logon requests are originating, and then find the user or application that is using the wrong password. Sometimes the name of the account can help. For instance, if the account name is the name of a service account, then you can be reasonably certain that you are looking for a miss-configured service. The "workstation" field in the logon audits tells you where the logon request originated". Why bother deciphering Event logs when GFI EventsManager can do everything for you? Free trial here! Anonymous (Last update 10/20/2004): This problem can also be caused by a variant of the W32/Sdbot.worm worm (McAfee says there are over 4000 variants). McAfee enterprise VirusScan missed this. We enabled Kerberos debugging and the netlogon file in the debug folder pointed out the machines infected. The security auditing event file can point out some of them, but some machines did not log to it. Registry editing and running the Trend Micro scanner repaired the machines in question. Anonymous (Last update 10/20/2004): Per a recent call with Microsoft, open the “Netlogon.log” file (in W2K, it is in “C:\WINNT\Debug”). Failed logon attempts will be noted here; look for the Error code 0xC000006A returned, which indicates a bad password. The system named is the one you should focus on as possibly running a service that is attempting to use an incorrect password to start. In our case, Dell IT Assistant was using a bad administrator password, and every status poll was generating a SAM error. Mateo Lee (Last update 8/18/2003): We ran into the same issue after changing domain admin account. This was very difficult to trace. Ended up logging into each server until I was not able to access with new domain admin credentials. Restarted the "NT LM Security Support Provider" service. Once I logged off, the new credentials worked. Jason S. Rundle (Last update 5/16/2003): You must analyze the error data to receive the correct error condition. DWord data hexadecimal 0xc00002a5 = decimal -1073741147: STATUS_DS_BUSY, ntstatus.h. See M306091. Mark Geschke This error proved to be very hard to track down and was occuring together with replication conflicts and other security audit failures (3221225578 - "User name correct but password wrong). Eventually we traced it back to a password change on our main domain "administrator" account and a service on another machine that was still trying to use the old password. This, however, resulted in failed connection attempts and the administrator account was declared as "Locked out" in AD even though we could still log on to the servers locally. When we renamed the administrator account, the security audit failures changed to "3221225572 - The username doesn't exist." and the new renamed administrator account stayed enabled and could be replicated successfully. |
| Links | M306091, M824209, M887433 |
| Search | Google Web - Microsoft Support - Bing - EventID.Net Queue - More links... |
| Custom search | The custom search information is available to subscribers only. |
| Feedback | Send comments - Notify me when updated |
| Print version |