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

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

I am having same problem. we have 70 DC,s in our orgnisation. but in logs i found multiple login failures for domain user, with event id 4771 or 4768, failure code 0x18, Bad password and source name as name of domain controller (dc007.in.rp.com). I dont understand how the login failures occur due to bad password, when the user has not attempted to logon.

I just had the same thing happen to me. My AD account was getting locked every couple of hours. I used the ALtools lockoutstatus.exe http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en to find the source DC that was locking me out. Tracked down the error next to the backup DC in the site. After running through the Security Logs around the same time I was locked out on the backup DC, I found an IP to another PC where I was locked for I don't know how long but it was before I recently changed my password. I rebooted the PC and cleared my account. Basic tasks-- find the DC that is locking you out. Find the reference for Event ID 4771 in the Security Log of that DC which in this case was the backup DC in the site. Go to the backup DC and find the same reference for Event ID 4771 in that DC and check the same time that you were locked out. It should show the source client PC's IP address that queried the BDC & subsequently locked me out.