Security – AD Administrator account logon thestery – last logon timestamp

We've found the domain Administrator account – which we do not use except in the event of a disaster recovery scenario – has a recent date in the LastLogonTimeStamp attribute. As far as I am aware, no-one should have used this account in the time period concerned (and several months beyond), but maybe some idiot has configured it to run a scheduled task.

Due to the quantity of security log events (and lack of SIEM tool for analysis), I wanted to determine which DC had the actual lastLogon time (i.e. not the replicated attribute) for the account, but I have queried every DC in the domain, and they each have a lastLogon of "none" for Administrator.

This is a child domain in the forest, so it's possible that someone has used this child domain Administrator account to run something in the parent domain.

Can anyone think of a way to determine which DC is doing the logon other than examining the potential 20 million events from 16 forest DCs around the time recorded in LastLogonTimestamp? I suppose I could target the parent domain DCs first (as the child DCs seem not to have done the auth).

Explanation

[Added after zeroing in on the cause after using repadmin per the below]

The original reason for this request was due to our IT Security team, who were wondering why we were apparently logging on with the default domain Administrator account on a frequent basis.

We knew that WE weren't logging it on. It turns out that there is a mechanism called "Kerberos S4u2Self" that's when a calling process running as Local System is doing some privilege escalation. It does a network logon (not interactive) as Administrator on a domain controller. As it's non-interactive, this is why there's no lastLogon for the account on any DC (this account had never been logged onto any current domain controller).

This article explains why the thing pings your logs and makes your security team have kittens (the source machines are Server 2003, to make things worse). And how to track it down. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/

Lesson learned – only provide reports on lastLogon attributes to IT security teams when it concerns Administrator logons.