Tracking Real User Logons Can Be an Uphill Battle
In the Active Directory world, every time a user logs in to the domain, several things occur. First, a Kerberos authentication request ticket occurs (i.e. 672 event) on the domain controller to request access. If the user is granted access, based on the correct logon and password entered, a successful authentication occurs (i.e. 673 event) on the domain controller. Subsequently, a successful local logon event occurs (528 event) on the client host that the user logged in from.
The Contrast between UNIX and Windows Logon Auditing
On UNIX systems, logons are very obvious and clear. When a user logs into a UNIX system, a single event occurs with a easy-to-read message that is generated on that system. Either, a successful or failed logon event is generated on the (named) host with the appropriate time-stamp, based on the action that has occurred. The UNIX/LINUX event logs are fairly easy to read and aren’t nearly as convoluted or misleading as the Windows event logs. The real problem with UNIX auditing is simply the need for central management and reporting.
In a Windows Active Directory environment, logon events are not that cut and dry. They are very hard to decipher and to correlate actions together.
In the Active Directory world, every time a user logs in to the domain, several things occur. First, a Kerberos authentication request ticket occurs (i.e. 672 event) on the domain controller to request access. If the user is granted access, based on the correct logon and password entered, a successful authentication occurs (i.e. 673 event) on the domain controller. Subsequently, a successful local logon event occurs (528 event) on the client host that the user logged in from.
Which logon event(s) should be collected for reporting?
During the course of every day, hundreds of duplicate successful authentications (i.e. 673 events) get spuriously generated by the Windows system auditing. The domain controller gets thousands of duplicate logon events every hour for each user that has logged in. These duplicate events are copies of the original logon event, however, they have different time stamps. The system generates these bogus duplicate events for unknown reasons. What is known is that these duplicate logon events are unnecessary to collect and report.
Which Event IDs are the authentic logon logs?
If Windows auditing generates duplicate logon events during every user’s logon session, how can the correct logons be collected?
How are these duplicate logon events affecting reporting and forensics?
How can anyone tell where a user’s audit trail really begins or ends?
At first glance, solutions that use the collect al model initially seem attractive, until someone actually has to investigate an incident or use the data for real compliance reporting purposes. Relying on logging systems that don’t perform intelligent event log analysis is a false sense of security. Not only are the logon sessions for each user questionable, but all the other activity immediately following the initial logon can be suspect due to the repeated logon authentications. These event logs could be disputed in an eDiscovery case or any other case for that matter.