Domain Controller Administrator Account Locked Event ID

Sachin Shinde 1 Reputation point
2021-07-23T06:58:13.243+00:00

Hi,

We have Domain Controller & Additional Domain controller in our environment. From last few days false event ID 4740 getting generated continuously for every second for Domain controller Administrator ID. Administrator account is not getting locked but event ID 4740 getting generates in Security event. We have not used administrator account for any service.

117376-image.png

Thanks & Regards,
Sachin Shinde

Active Directory
Active Directory
A set of directory-based technologies included in Windows Server.
6,091 questions
{count} votes

8 answers

Sort by: Most helpful
  1. Hannah Xiong 6,241 Reputation points
    2021-07-23T07:29:41.34+00:00

    Hello @Sachin Shinde ,

    Thank you so much for posting here.

    The built-in domain administrator account will not be locked out actually. It still could be successfully logged in as soon as the correct password is used.

    I did the test in my lab. Configured the account lockout policy as shown below. Logged on to the BDC with the domain admin account and typed the wrong password many times. There were events logged on the BDC as shown below.
    117343-image.png

    117396-image.png

    Then on the PDC, I could see the event ID 4740 and 4771. Even though there is event 4740, the admin account could still be logged in as soon as the correct password is used.

    117378-image.png

    Please note that only the built-in administrator account will not be locked out.
    Have we made any changes from last few days, such as changing the password of this account?
    Next to event 4740, could we find the event ID 4771 or 4776? If we could find the event 4771, then we could find out the failure code.

    For more information about event 4771, please refer to:
    https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4771

    For any question, please feel free to contact us.

    Best regards,
    Hannah Xiong


  2. Sachin Shinde 1 Reputation point
    2021-07-27T05:26:04.297+00:00

    Hi,

    Still getting events for 4740 without locking admin account.

    118191-image.png

    We have renamed Administrator account to Parrot while implementation 2-3 years before. No password changed recently or password policy applied for User container (OU).

    Thanks,
    Sachin Shinde


  3. Sachin Shinde 1 Reputation point
    2021-07-27T10:22:11.937+00:00

    Hi,

    Yes event ID 4771 is around to event ID 4740. No event ID for 4776. Caller computer name is Domain controller.

    Thanks,
    Sachin Shinde


  4. Sachin Shinde 1 Reputation point
    2021-07-28T04:21:16.753+00:00

    Hi,

    Yes failure code is 0x18, but actually account is not getting locked. Parrot (Admin ID) is not at all getting locked but only it generates event ID 4740 for this account. My concern is only that why it is generating false event IDs for this account.

    Thanks,
    Sachin Shinde

    0 comments No comments

  5. Hannah Xiong 6,241 Reputation points
    2021-07-28T05:27:38.923+00:00

    Hi Sachin,

    Thank you so much for your kindly reply.

    Yeah, as mentioned in the first response, the built-in administrator account will not be locked out. So in our case, the account is not getting locked out but there will be event 4740 recorded for the account.

    We are trying to figure out why there is event 4740 for this account. Normally there should be no false event IDs. If there is event recorded for the account, it should be triggered by some operations.

    Normally, the reason the user is locked is that a certain process (caller process) on a certain machine (caller computer) stores the user's wrong credential, and this process uses the wrong credential to initiate authentication requests to domain controllers. After reaching a certain number of times(Account lockout Threshold), our account will be locked. (It will not be locked out for the built-in admin account.)

    Now we have found out the caller computer. Then we logon to the caller computer and if we have configured audit policy as Audit Logon Events – Failure, we can filter 4625 event in security. From 4625, generally we could trace the process name. And check following possible cause.

    a. Stored user names and passwords in credential manager
    b. Persistent drive mappings.
    c. Scheduled tasks.
    d. Third-party application stored the wrong password.
    e. Clear logon session by running the following command:

    Get-WmiObject Win32_LogonSession | Where-Object {$.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($.LogonId, 16))}

    f. Use PStool to check if there’s any cache password in system:
    i. Download PsExec.exe from http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx and copy it to C:\Windows\System32.
    ii. From a command prompt run: psexec -i -s -d cmd.exe
    iii. From the new DOS window run: rundll32 keymgr.dll,KRShowKeyMgr
    iv. Clear the cache in it.

    118493-image.png

    For any question, please feel free to contact us.

    Best regards,
    Hannah Xiong

    ============================================

    If the Answer is helpful, please click "Accept Answer" and upvote it.

    0 comments No comments