Windows Logon-Logoff Research
- Pavan Raja
- Apr 8, 2025
- 7 min read
Summary:
The document outlines a method for analyzing user logon and authentication events from domain controllers and workstations within a Windows environment. Key points include the distinction between local (logon type 2) and network (logon type 3) logons, with successful local logons recorded as Event ID 528 and successful network logons (from both laptops and file servers) logged as Event IDs 540 for laptops and 538 for file servers. Failed logons are only trackable locally at the workstation. Proper user login/logout activity reports should show around four entries per user, with incorrect classifications leading to inaccuracies in tracking actual user activities. The document also highlights specific event types (Event ID 529) that can be used to generate reports on which users have accessed a particular file server or laptop during a specified time period.
The article further discusses the use of event IDs 672 and 680 for tracking authentication events in Windows Server 2003, with Event ID 672 focusing on Kerberos ticket grants and service tickets, while Event ID 680 tracks NTLM logons when they occur via non-Kerberos methods. It's important to note that Microsoft has changed the logging of these events over time: in Windows 2000, only successful TGT grants were logged with Event ID 672, whereas Windows 2003 logs both successes and failures for this event. Furthermore, Event ID 681 from Windows Server 2003 was merged into Event ID 680 to consolidate the logging of all authentication events.
The article also provides guidance on filtering sessions in a Session List to focus specifically on activities related to particular users or systems by utilizing various criteria such as user name, event IDs, and types of logons. This functionality allows for tailored analysis based on specific needs, enhancing the efficiency with which security audits can be conducted and reported upon.
In summary, this document serves as a guide for IT professionals and system administrators to interpret and utilize authentication logs from Windows systems in order to enhance network security management practices, improve audit processes, and support overall user accountability within an organization's digital infrastructure.
Details:
The provided information outlines a method for analyzing user logon and authentication events from domain controllers and workstations within a Windows environment. Here's a summary of the key points:
1. **Log Types**:
**Logon Type 2** (from a laptop): Indicates a local logon, where the user logs into their own device before accessing network resources.
**Logon Type 3** (from a file server): Indicates a network logon, where credentials are used to access files on a file server. This is typically done through an authenticated session initiated by the workstation or laptop.
2. **Event Mapping**:
A successful local logon results in Event ID **528**.
Successful network logons (from either laptops or file servers) are recorded as Event ID **540** for laptops and Event ID **538** for file servers.
3. **Local vs Network Logons**:
Local logons involve direct user interaction with the device, such as logging into a laptop or workstation. These logs include both successful logins (Event 528) and failed attempts (which are logged locally at the workstation).
Network logons occur when credentials are used to access network resources via file servers; these are captured by Event ID 540 from laptops and Event ID 538 from file servers.
4. **Failed Logon Tracking**:
Failed logons, whether they be at the workstation or domain controller level, can only be accurately tracked locally at the workstation where the attempt was made. This is because failed logons are not logged by the domain controller.
To track all types of failed logons in Active Directory (AD), one should monitor the account authentication events, as these include both successful and failed authentications.
5. **Reporting**:
A proper user login/logout activity report for a day should ideally show around four entries per user: two logon entries and two logoff entries.
Incorrectly classifying hundreds of log entries as type 3 (network) can be misleading, leading to inaccuracies in tracking actual user activities.
6. **Event IDs**:
Event ID **528** represents a successful local logon.
Event ID **540** is used for network logons from laptops.
Event ID **538** is used for network logons from file servers.
7. **Usage and Collection**:
The events should ideally be captured directly at the source (either domain controllers or workstations, depending on the type of logon).
In a large-scale scenario with multiple users, collecting logs from 7 domain controllers resulted in seeing only event types 528, 528 (repeatedly for failed attempts), and 540.
This summary provides a clear framework for understanding how to interpret and analyze user logon activities based on the provided events and their implications for reporting and tracking purposes.
Event 540, known as "Successful Network Logon," occurs when a user from an external network connects to a resource via the Server service on a computer. The logon can be either type 3 (normal network logon) or type 8 (network logon with clear text authentication), particularly for IIS web-site connections using Basic Authentication. It's important to note that most Basic Authentication over SSL is secure and does not typically result in logon type 8, so this should not immediately raise alarms unless it involves unencrypted HTTP access.
This event logs whether the account used for logging on is local or a domain account. For more detailed explanations of related events (515 for Logon Processes and 514 for Authentication Packages), refer to those specific documentation entries, as well as the general descriptions provided in the article excerpt. The Logon GUID remains undocumented, and the purpose of Caller User Name, Caller Process ID, and Transited Services fields is unclear.
Source Network Address corresponds to the workstation's IP address, while Source Port refers to the TCP port on the workstation, which are both considered reliable for correlation purposes. Lastly, Logon ID can be useful in correlating with other events that occur during this logon session.
Event 672 in Windows operating systems (particularly on domain controllers) logs authentication events, including successful logins and other activities like booting computers for Kerberos ticket requests. It provides information such as the original user account (logged-on user), the new user account being used (user whose credentials were used), caller process ID, and network details.
In Windows 2000, event ID 672 is specific to domain controllers and indicates a successful authentication ticket grant (TGT) when a user logs on with correct credentials. The User field always reads "SYSTEM", but other fields like User Name and Supplied Realm Name provide information about the actual user logging in and their domain suffix. Client Address shows the IP address of the workstation from which the login occurred, while Win2k also logs event 672 at system startup or reboot for authentication requests by computers in the domain.
In Windows 2003, this event is logged on domain controllers with both success and failure entries, indicating a TGT request made during user logon and other computer-initiated authentications like system starts or reboots.
This summary discusses the events and processes related to Kerberos authentication in Windows operating systems (W2k and W3). Event ID 672 occurs when a local domain controller (DC) grants a Ticket Granting Ticket (TGT) after successful username and password verification, along with status and restriction checks. The event logs indicate that the user is SYSTEM, but supplementary fields like User Name and Supplied Realm Name provide information about the authenticated user and their DNS suffix. Client Address shows the workstation's IP address from which the login occurred.
For computer-generated kerberos events such as when a computer in the domain authenticates to the DC (e.g., at startup or restart), the User Name and User ID fields include the computer name, with special notation for computers using Kerberos encryption types like PKINIT.
Event ID 676 is triggered for both successful and failed authentication attempts; however, in Windows 3 (W3), this event combines information about both success and failure. The reason for a failed authentication attempt is detailed in the Result Code field. If audit details from logon events 528 and 540 are already collected, additional information may not be necessary.
Event ID 673 pertains to service ticket grants; it tracks access granted after successful authentication through Kerberos, with specific variations depending on the OS (Win2000 in this case). This event monitors the granting of service tickets upon user or computer access to network services, such as accessing a file server. The occurrence of these events helps track and audit the flow of Kerberos ticket grants and usage within an organization's network security framework.
Event ID 673 on a domain controller (DC) logs details about service ticket requests, including user information, accessed server name, and client IP address. It helps monitor network accesses like mapping drives to file servers. For failed requests, the failure code specifies the reason. This event is specific to DCs and tracks both successful and failed service ticket requests.
Event ID 680 on a domain controller logs details about user logons when authenticated via NTLM (non-Kerberos) method. It identifies the account used for logging in, along with the client computer's name during the logon attempt. This event is logged only on member servers and workstations for local SAM accounts.
This summary pertains to changes in event logging for authentication on Windows Server 2003. Microsoft removed event ID 681 and unified it with event ID 680, which now covers both successful and failed NTLM authentication attempts. Users should look for event ID 680 and consider the success or failure status indicated by this event. The reasoning behind this change is that similar activity was already recorded by other events.
Additionally, there's a distinction between two types of log-ons mentioned in the encyclopedia notice: event ID 672, which tracks initial logons where tokens are granted (referred to as "interactive log-on"), and its counterpart which allows tracking these initial logons through the granting of Ticket Granting Tickets (TGTs).
Finally, the summary mentions that you can filter events in a Session list to only show those from a specific user, such as PDavis. This is important for focusing on logs relevant to particular users or system activities.
Comments