What is causing my Domain Controller to log dozens of successful authentication attempts per second?

We have a domain with about 15 servers and about 30 workstations. Servers are mostly 2008r2 and workstations are mostly Windows 7. The two DCs are 2012r2. Every few weeks, one of our admin accounts gets locked out. I'm trying to narrow down the cause and I've reached a dead end.

Here's what I have.

The event log on the PDC shows event 4776 - audit success:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

All for the same username and recurring several times a second.

Based on the event IDs, these are NTLM logins rather than Kerberos. Though the type of authentication used is less worrisome to me than the shear quantity. This happens several times a second and repeats every couple of seconds ad infinitum, all hours day or night or weekend.

The event log also shows audit success event ID 4624 (logon) and 4634 (logoff) for this username, but as in the event above the "workstation" field is empty.

I enabled verbose netlogon logging and the netlogon.log shows

02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Returns 0x0

And so on and so forth. The apparent source of these logins (via XYZ) may include workstations and servers from across the network.

Clearly this looks like an automation or script. Since the logins are generally all successful, I do not believe it's an intrusion attempt. Some of the logins, however, do fail from time to time but I have not identified any pattern to the failure and they occur so infrequently that (most days) they don't lock the account out. The failure code when there is one is usually 0xc0000022 (Access Denied)

I've disabled and uninstalled our remote monitoring agent (currently Kaseya, but we're finally moving to LabTech) from one of the servers, but still saw new events originating from that server, so this rules out automation tasks. I've also checked task scheduler on a couple of servers and found nothing out of the ordinary. I've checked services to verify logon accounts and this account is not used in any services.

I ran Netstat for a good long while and saw primarily connections to the PDC from "System" and "System Idle Process". I did see occasional connections from spoolsrv and lsass and ismserv (the server I'm testing on is a Citrix XenApp server, but other "source" servers are not in the XenApp farm, and of course "source" workstations are not either). I stopped the print spooler service just to test and it had no impact on the login events.

I work at an MSP and this is our primary technician dom admin account, so it's high priority that it be working and be secure. The last idea I have left is to change the password and see what breaks, but without knowing what the account is being used for this could have potentially catastrophic consequences. However, my suspicion is that this might just be a misconfigured AD.

Has anyone experienced something like this before and been able to identify the source?

I recommend further enabling NTLM auditing on your DC's. Using the Default Domain Controller Policy, enable the following policy settings:

Network security: Restrict NTLM: Audit Incoming Traffic = Enable auditing for all accounts Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit All

https://support.symantec.com/en_US/article.HOWTO79508.html

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865682(v=ws.10)

Once enabled, Navigate in your event viewer to: Applications and Services Logs > Microsoft > Windows > NTLM > Operational

There will be event(s) with timestamps matching your netlogon event timestamps. This log will reveal the actual Workstation Name.

And specifically to help you identify further the source, the Secure Channel Name in this log would help narrow down the process origination.