Can someone help me with this. Over the last few weeks, a users account is constantly getting locked out, without them trying to log on. I wanted to being to find out where the login attempts are originating. In the Event I see Network Information Client Address: ::ffff:192.168.x.x Client Port: 4889 well this address happens to be one of our domain controllers. Can anyone help me understand if this domain controller (which is a backup DC, not FSMO roles) is taking part in the lockout? Users Password has not been change in a few weeks. Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 3/23/2011 9:58:35 AM Event ID: 4771 Task Category: Kerberos Authentication Service Level: Information Keywords: Audit Failure Description: Kerberos pre-authentication failed.

You're able to hunt down a lockout with Altools lockoutstaus: http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en Then track down the event that you've posted. In normal circumstances you would find this event on PDC as last,due to the logic how the account is verified. That will show that the lockout is coming from a domain controller, however that is just passing the logon to PDC for last verification. You have to go on that domain controller and check the failure events before the time they've appeared on the PDC. If the error you're posting is not from a PDC and in fact the originator is the domain controller , check the services and the scheduled tasks as the first thing (if they don't utilize the account). Also , it's not quite clear if this is one user only ... if the userbase is unusually large , it indicates that you have an Virus infection in place

a) you see the IP address of the computer on which the user (whos login must be part of the event log as well) actually asked for authentication and creation of TGT ticket. That means that the user's password must be provided at that precise computer. b) the pre-authentication means just the fact that the user's password supplied does not match what is stored in database. c) how could have the password appear on the computer? it might have been something like - local interactive logon, terminal services logon, any service running under that user account, IIS/SMTP/FTP/... Basic Authentcation, etc. ondrej.

thanks Alex - tried using the tool but crashed on both 2k8r2 and win7 machines. The error was posted on the PDC but originated from the Backup DC. The users account that was locked out is a regular use, with no power privileges. And there are no services/task or anything on any server that utilize this account. IT is a normal user account. We have a total of 30 user accounts in AD - very small. IF there was a virus infection in place - and clearly SEP is not picking it up, any other suggestions? Thanks - SJMP

A) the user would not log on to the DC, they do not even know that it exists. The users password was not provided (unless we are talking hack) C) again this is a normal user (domain member, nothing more). Their account is not tied to any services - anywhere, not on a local machine, not on any server.

Sorry forgot to ask you about your environment before suggesting the tool..What i've meant is that you have to follow the chain , so the real client IP will be visible from the log on the Backup DC. anyway , if it's a simple user with no privileges the most likely cause is a saved password in a client application (IE , Citrix, etc..) on his workstation

Not problem. I should have mentioned that. But at what point would that client be accessing anything local (IE, no citrix in ENV) - that would try to authenticate with the DC. I dont understand how the windows account is locked due to bad password, when the user has not attempted to logon. Thanks, SJMP

Generally, this occurs when something is mapped with an account and password. This can be something as simple as a mapped drive, cached password in a scheduled task or service, etc. So, once you identify the source machine you should be able to identify where the credential information is stored.fr3dd

SJMP i can't guess your environment , so it's hard to say what can utilize an user logon (even if the user is not actually in the office sitting behind his PC)... for example we had an application that was running reports under stored user credentials, once you've logged on it was using your credentials to run some sort of reports on your behalf with the same credentials forever So probably the best way to go is to reveal the real client IP as described above and examine that machine what is running on it

I had the same problem!!! I resolved it by finding out which computer was causing my account to be locked out, and then going to the credential manager in the control panel and removing my username and password from the list. I actually deleted every username and password from the list. To find the computer that is locking out the account, is search the security error log on the server for the time that you were locked out. Once you find out which PC it was, then pull the system log on that system and look to see if there is an error at the same time. If it is you got it so just remove the creds from the cred mgr and I think that the problem might be solved. Btw also I had my account locked out because I used my username and password to login to the AV update server to get updates for a workstation. That that locked out my account about every 30 minutes. Hope this helps!! Kev