Account Locked - Event 4771 Failure Code 0x18
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.
March 23rd, 2011 10:26am

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
Free Windows Admin Tool Kit Click here and download it now
March 23rd, 2011 7:41pm

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.
March 24th, 2011 7:17am

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
Free Windows Admin Tool Kit Click here and download it now
March 24th, 2011 9:40am

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.
March 24th, 2011 9:42am

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
Free Windows Admin Tool Kit Click here and download it now
March 24th, 2011 11:14am

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
March 24th, 2011 12:54pm

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
Free Windows Admin Tool Kit Click here and download it now
March 24th, 2011 1:23pm

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
March 24th, 2011 3:08pm

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
Free Windows Admin Tool Kit Click here and download it now
June 22nd, 2011 3:49pm

This help me a lot!!! Thanks Kevin!!!!
July 10th, 2012 5:48pm

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.
Free Windows Admin Tool Kit Click here and download it now
August 1st, 2012 7:07am

I had the same problem and reading through these posts helped me. As someone said above, you have to track the chain. I had my PDC recieve failed logon's for my administrator account, from the BDC (we have 4 DC"s btw, 3x08r2 1x03). And at the same time I was recieving logon failures on the BDC for the account coming from a particular PC name/IP. I logged into that PC remotely and sure enough, there was an entry for administrator in the windows credentials vault (on win 7 or 08, just type "vault" into the search bar of control panel to find it) I removed that entry and that has cleaned up my logs. No more bad password attempts. Now, your 70 DC's will take a bit, but these lockouts happen for the most annoying reasons and they can drive you batty trying to find the culprit. Several things I have found are as others have mentioned. Saved internet logins, saved windows credentials, mapped drives with explicit usernames etc. So check your logs, trace it back through your chain of DC's and see where the client is that is causing the lockout, and then investigate all the little things running on it. Hope my experience helps.Troy Michie
August 16th, 2012 8:14pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics