Automatic AD Account Lockouts

A domain controller shown in Event 4625 is not necessarily the original source; identify the DC processing the lockout with LockoutStatus.exe, then enable Netlogon debug logging on that DC to trace the upstream computer or authentication intermediary.

Trace the next lockout

1. Run LockoutStatus.exe for the service account.
   It is included in Microsoft’s Account Lockout and Management Tools and identifies the domain controllers involved in the lockout. Its output can also be exported to CSV. ^1^
2. On the DC processing the bad-password attempts, open an elevated Command Prompt and enable Netlogon logging:

      nltest /DBFlag:2080FFFF
   
      rem After the next lockout:
      findstr /i "serviceAccountName" %windir%\debug\netlogon.log
      findstr /i "serviceAccountName" %windir%\debug\netlogon.bak
   

   Netlogon writes to %windir%\debug\netlogon.log; restarting Netlogon is normally unnecessary on Windows Server 2012 R2 and later. The default log is 20 MB and rotates to netlogon.bak, so check both files after a lockout. ^2^
3. Correlate by timestamp, not only by computer name.
   Search just before the 4740 lockout time for the service account and bad-password status. The matching Netlogon entries can identify:
   • the originating workstation or server;
   • a server forwarding the request;
   • an authentication intermediary, such as an application, network appliance, or other service.
4. Disable verbose logging after capturing the event:

      nltest /DBFlag:0x0
   

   Confirm that %windir%\debug\netlogon.log is no longer receiving entries. ^2^

Why the DC can appear as the caller

Event 4625 is generated on the computer where access was attempted. Its Subject and Process Information can describe the local service or process handling the request, while Network Information describes a remote origin only when that information is available. The workstation field can be blank or reflect an intermediate system. ^3^

Therefore, a DC address in 4625 may mean:

• a process really is running locally on the DC;
• another system submitted authentication through that DC;
• the DC is the visible authentication hop, while the original endpoint was not preserved in the event.

It is not sufficient by itself to conclude that a scheduled task, service, or application on the DC supplied the bad password.

After Netlogon identifies a host or intermediary

Since tasks, services, and COM+ registrations on the known computers have already been checked, pivot to credential sources that may not appear there:

• IIS application pools or application-specific connection settings;
• Windows Credential Manager and stored network credentials;
• mapped drives or persistent SMB sessions;
• backup, monitoring, antivirus, deployment, or management agents;
• scripts and applications using embedded credentials;
• NAS, VPN, RADIUS, Wi-Fi, printers, scanners, or other appliances;
• decommissioned or intermittently connected machines;
• AD FS or Web Application Proxy, if those roles are present.

If the trace identifies a client but not its process, ALockout.dll can help identify the application submitting wrong credentials. Do not install it on servers hosting network applications or services, or on Exchange Server, because Microsoft documents that it can interfere with those workloads. ^1^

If the Security logs do not contain enough authentication detail, enable the relevant Advanced Audit Policy settings—particularly Audit Credential Validation, Audit Kerberos Authentication Service, and Audit Logon—on the affected DCs rather than broadly across the domain. Microsoft’s Windows Server baseline recommends success and failure auditing for these categories. ^4^

References

1. Introduction to Account Lockout and Management Tools
2. Enabling debug logging for the Netlogon service
3. Domain Controller doesn't allow interactive logon, shows an error: The security database on the server does not have a computer account for this workstation trust relationship
4. System audit policy recommendations