none
Kerberos Pre-Auth Lockouts RRS feed

  • Question

  • I have been getting locked out of my admin account every 1 hour and 1 second since changing my password. Before changing my password I enabled FIPS on the domain controllers. My account will stop locking out if I go to account settings and disable Kerberos Pre-Authentication. The funny thing is setting my password back to what it was did not fix the problem. If I turn on Kerberos Pre-Auth it doesn't lock, turn it back on and it locks every hour.

    I did all the normal stuff. Checked processes, scheduled tasks, mapped drives, logons from other machines, etc. I don't have any creds stored in credential manager and I even wiped out my local profile.

    I created a scheduled task that gets triggered off a 4740 lockout event. Why? So I can see if someone is brute forcing our domain. The scheduled task has my domain admin account as the author but is setup to run as a service account. I can see in the security events that it locks my account then right after the service account runs this task. I'm not logged on anywhere else in the domain and the lockouts are coming from the domain controller.

    I created a second domain admin account, changed the password, and this one is not getting locked out. 

    In the registry the only two credentials that are stored are for service accounts. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\CredWom 

    Here is the event, slightly modified by me. It doesn't tell me the process that is locking me out.



    A user account was locked out.

    Subject:
    Security ID:  SYSTEM
    Account Name:  DOMAINCONTROLLER$
    Account Domain:
    DOMAIN
    Logon ID:  0x3E7

    Account That Was Locked Out:
    Security ID:  DOMAIN\joe.alves.adm
    Account Name:  Joe.Alves.Adm

    Additional Information:
    Caller Computer Name:
    DOMAINCONTROLLER

    Here is one of the Kerberos Pre-Auth errors before the lockout.
    Kerberos pre-authentication failed.

    Account Information:
    Security ID: Domain\Joe.Alves.Adm
    Account Name: Joe.Alves.Adm

    Service Information:
    Service Name: krbtgt/mwglan01

    Network Information:
    Client Address: ::1
    Client Port: 0

    Additional Information:
    Ticket Options: 0x40810010
    Failure Code: 0x18
    Pre-Authentication Type: 2

    Certificate Information:
    Certificate Issuer Name:
    Certificate Serial Number:
    Certificate Thumbprint:

    Certificate information is only provided if a certificate was used for pre-authentication.

    Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

    If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.

    Here is an example of how my scheduled tasks are setup. I am the author of these but my account is not used to run them.

    <?xml version="1.0" encoding="UTF-16"?>
    <Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <RegistrationInfo>
        <Date>2019-02-24T12:26:17.8640552</Date>
        <Author>Domain\joe.alves.adm</Author>
        <Description>E-mails notification when account is locked out.</Description>
      </RegistrationInfo>
      <Triggers>
        <EventTrigger>
          <Enabled>true</Enabled>
          <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Security"&gt;&lt;Select Path="Security"&gt;*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4740]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
        </EventTrigger>
      </Triggers>
      <Principals>
        <Principal id="Author">
          <RunLevel>HighestAvailable</RunLevel>
          <UserId>Domain\SVCTask SchedulerDC</UserId>
          <LogonType>Password</LogonType>
        </Principal>
      </Principals>
      <Settings>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
        <AllowHardTerminate>true</AllowHardTerminate>
        <StartWhenAvailable>false</StartWhenAvailable>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <IdleSettings>
          <StopOnIdleEnd>true</StopOnIdleEnd>
          <RestartOnIdle>false</RestartOnIdle>
        </IdleSettings>
        <AllowStartOnDemand>true</AllowStartOnDemand>
        <Enabled>true</Enabled>
        <Hidden>false</Hidden>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
        <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>
        <WakeToRun>false</WakeToRun>
        <ExecutionTimeLimit>P3D</ExecutionTimeLimit>
        <Priority>7</Priority>
      </Settings>
      <Actions Context="Author">
        <Exec>
          <Command>powershell.exe</Command>
          <Arguments>-command C:\Scripts\4740_Lockouts.ps1</Arguments>
        </Exec>
      </Actions>
    </Task>








    Saturday, November 9, 2019 6:22 PM

All replies

  • Hi,

    Thanks for posting here!

    I would recommend you find the event 4625 through the logon id.

    And then check the process in the event 4625.

    Please feel free to let us know if you need further assistance.

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, November 11, 2019 9:17 AM
  • I don't have 4625 events under Security. This is Server 2012 R2 so those events should apply and I do have all logging turned on under GPO advanced auditing. I do have 4625 events under Application but they are irrelevant. My understanding is that 4625 events are logged on the computer making the call and the 4740 says it's the domain controller making that call but doesn't list the process.

    I do have 4688 events but they don't show my admin account running anything. All I see from that time is the service account running task scheduler which kicks off PowerShell to e-mail me that my account is locked out.

    I'm noticing DNS and DHCP events keep coming up right before the lockout and am considering stopping those services to see if one of them is doing something weird.

    I am getting these 4771 events. Client Address is ::1 Port 0.

    Kerberos pre-authentication failed.

    Account Information:
    Security ID: Domain\Joe.Alves.Adm
    Account Name: Joe.Alves.Adm

    Service Information:
    Service Name: krbtgt/Domain

    Network Information:
    Client Address: ::1
    Client Port: 0

    Additional Information:
    Ticket Options: 0x40810010
    Failure Code: 0x12
    Pre-Authentication Type: 0

    Certificate Information:
    Certificate Issuer Name:
    Certificate Serial Number:
    Certificate Thumbprint:

    Tuesday, November 12, 2019 12:08 AM
  • Hi,

    In your situation , i would recommend you use the account lockout tools for troubleshoot.

    For your reference:

     https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738772(v=ws.10)?redirectedfrom=MSDN

    Have a nice day!

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, November 12, 2019 5:44 AM
  • I've used account unlock. It's nothing special unless you're in a big domain and don't know where you're getting locked out. I know which domain controller I am getting locked out on. It's the same controller every time. And yes I have used eventcombmt as well.
    Tuesday, November 12, 2019 1:42 PM
  • Hi,

    The ALockout.dll tool and the Appinit.reg script are included in the ALTools package. ALockout.dll is a logging tool that may help you determine the program or process that is sending the incorrect credentials in an account lockout scenario. 

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, November 13, 2019 6:06 AM
  • Account Unlock is for 2003. A lot of these features no longer apply. I've run the Appinit.reg script and rebooted and the ALockout.dll is in my System32 folder and the debug logs don't exist in %System32%\Debug. Regardless this is irrelevant to 2012 Domain. Everything should be in the Security logs but the Computer calling the process is the domain controller and it doesn't tell me the process.
    Wednesday, November 13, 2019 9:56 PM
  • Hi,

    About this problem , i would do more research.

    If there are any progress, i will get back to you . I appreciate your patience.

    If you have any updates during this process, please feel free to let me know.

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, November 14, 2019 9:24 AM
  • No one with some deep knowledge or Kerberos Pre-Authentication has anything to add? 

    If I reboot the domain controller the lockout times change. It will startup a little over an hour after reboot and then lockout 1 hour and 1 minute after that. So there is something going on weird with the Primary Domain Controller. It's only this one account too. Like I said above the lockout says it is coming from the DC however it doesn't have a process. There are no scheduled task, processes, mapped drives, anything under my name. I completely ripped the profile off the server and still an issue. I've reset the password back to the password before the lockouts started and that didn't fix it so it's obviously not a password mismatch. It's a really odd issue. If I turn off Kerberos Per-Authentication the issue goes away. I've used procmon, Microsoft Message Analyzer, Wireshark and can't find anything going on during the lockout. I've dug through every log on that domain controller and nothing.

    The only responses I've relieved are from people who didn't read and understand the issue. 

    Sunday, December 1, 2019 6:31 PM
  • Hi,


    Here is one of the Kerberos Pre-Auth errors before the lockout.
    Kerberos pre-authentication failed.

    Account Information:
    Security ID:  Domain\Joe.Alves.Adm
    Account Name:  Joe.Alves.Adm

    Service Information:
    Service Name:  krbtgt/mwglan01

    Network Information:
    Client Address: ::1
    Client Port:  0

    Additional Information:
    Ticket Options: 0x40810010
    Failure Code:  0x18
    Pre-Authentication Type: 2

    The value of failure code means that is a bad password. in the following link you find all details about all failure code value Kerberos pre-authentication failed


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/


    Sunday, December 1, 2019 7:40 PM
  • Hi,

    Welcome to share your current situation.

    Please feel free to let us know if you need further assistance.

     

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, December 2, 2019 2:37 AM
  • I've already established that.
    Monday, December 2, 2019 1:09 PM
  • Does anyone actually read these or they just post useless technet articles for points? If you post a technet article I can guarantee I've already read it and it's not the right answer. 

    I need to know the SOURCE of the KERBEROS PRE-AUTHENTICATION lockouts and it's not showing on the event.

    Monday, December 2, 2019 1:11 PM
  • Hello Joe,

    You could try the following. Create a text file (with a name like "providers.lst") containing these two lines:

    "Security: Kerberos Authentication" 0xFFFFFFFFFFFF 255
    Microsoft-Windows-Kernel-Process 0x10

    Then issue the command "logman start lockouts -ets -pf providers.lst -o lockouts.etl" just before you expect the problem to occur and issue the command "logman stop lockouts -ets" when it has occurred.

    Keeping the trace period as short as possible would be very useful.

    Depending on the amount of Kerberos activity, one might need to modify the command to increase the level of buffering (lockouts.etl will record how many events if had to drop because of lack of resources - zero drops is obtainable and desirable).

    The file lockouts.etl might help track down what is causing the problem, but it is difficult to analyse. If you can create such a trace and are prepared to share it here, then I will take a quick look to see if anything stands out.

    Gary

    Monday, December 2, 2019 2:07 PM
  • Thank you Gary. I'll try to get that in the next couple days and post the results.
    Monday, December 2, 2019 3:00 PM
  • Hi,

    Welcome to share here if you have any progress.

    If there is still no progress, I would suggest you contact Microsoft Customer Services and Support to get an efficient solution:

    http://support.microsoft.com/contactus/?ln=en-au

    Have a nice day!

     

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, December 3, 2019 1:27 AM
  • I ran the trace and am still having trouble tracking this down. I had to import into Microsoft Message Analyzer and it's giving me the same stuff I saw in procmon. I looked at the time on the lockout and it was at 2019-12-05T00:16:33.454586100Z. 

    In MMA the time skips from 16:33.42 to 16:33:46. All the events in that range though are Process ID 728 which is lsass.exe. This is in line with what I found running a procmon.

    So the question is what is trigger lsass.exe to request a Kerberos ticket for an account that is not logged on anywhere, has no mapped drives, has no scheduled tasks, etc?  I do have iscsi drives attached to the SAN for backups but they are not using this account either.

    

    Thursday, December 5, 2019 12:36 AM
  • Also something I have noticed in both logs, the procmon, and this trace is that the process before lsass.exe is dns. I don't see how dns can be doing this though.
    Thursday, December 5, 2019 12:38 AM
  • Hello Joe,

    As you probably suspect, the key information is in the body of the events and not in the event headers. We will need access to the binary .etl file to mine as much information as possible from those event bodies.

    Gary

    Thursday, December 5, 2019 8:27 AM