none
Account Locked - Event 4771 Failure Code 0x18

    Question

  • 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.

     

    Wednesday, March 23, 2011 2:26 PM

Answers

  • 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

    • Marked as answer by SJMP Monday, March 28, 2011 3:31 PM
    Thursday, March 24, 2011 7:08 PM

All replies

  • 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

    • Proposed as answer by XxBanexX Thursday, February 13, 2014 2:49 PM
    • Unproposed as answer by XxBanexX Thursday, February 13, 2014 2:49 PM
    Wednesday, March 23, 2011 11:41 PM
  • 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.

     

    Thursday, March 24, 2011 11:17 AM
  • 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

    Thursday, March 24, 2011 1:40 PM
  • 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. 

    Thursday, March 24, 2011 1:42 PM
  • 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

    Thursday, March 24, 2011 3:14 PM
  • 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

    Thursday, March 24, 2011 4:54 PM
  • 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
    Thursday, March 24, 2011 5:23 PM
  • 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

    • Marked as answer by SJMP Monday, March 28, 2011 3:31 PM
    Thursday, March 24, 2011 7:08 PM
  • 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

    Wednesday, June 22, 2011 7:49 PM
  • This help me a lot!!! Thanks Kevin!!!!
    • Edited by kacomen Tuesday, July 10, 2012 9:49 PM
    Tuesday, July 10, 2012 9:48 PM
  •  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. 
    Wednesday, August 01, 2012 11:04 AM
  • 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

    Friday, August 17, 2012 12:11 AM
  • 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.

    • Proposed as answer by joedo5 Saturday, December 01, 2012 4:31 AM
    Saturday, December 01, 2012 4:31 AM
  • I just resolved one similar case, from DC security event:

    Event Type: Failure Audit
    Event Source: Security
    Event Category: Account Logon
    Event ID: 675
    Date:  27/2/2014
    Time:  10:58:38 AM
    User:  NT AUTHORITY\SYSTEM
    Computer: *********
    Description:
    Pre-authentication failed:
      User Name: *******
      User ID:  *******
      Service Name: krbtgt/***.*****.COM
      Pre-Authentication Type: 0x2
      Failure Code: 0x18
      Client Address: 10.***.**.**

    We traced the client address to our XEN apps server, apparently user has a previous disconnected session, due to improper logoff, we just manually logoff his session.


    • Edited by Desmond Yong Thursday, February 27, 2014 3:35 AM
    Thursday, February 27, 2014 3:28 AM