What security events get logged when a user logs on to their workstation with a domain account and proceeds to run local applications and access resources on servers in the domain?

When a user logs on at a workstation with their domain account, the workstation contacts domain controller via Kerberos and requests a ticket granting ticket (TGT).  If the user fails authentication, the domain controllers logs event ID 4771 or an audit failure instance 4768.  The result code in either event specifies the reason for why authentication failed.  Bad passwords and time synchronization problems trigger 4771 and other authentication failures such as account expiration trigger a 4768 failure.  These result codes are based on the Kerberos RFC 1510 and in some cases one Kerberos failure reason corresponds to several possible Windows logon failure reasons.  In these cases the only way to know the exact reason for the failure is to check logon event failure reason on the computer where the user is trying to logon from.

If the user’s credentials authentication checks out, the domain controller creates a TGT, sends that ticket back to the workstation, and logs event ID 4768.  Event ID shows the user who authenticated and the IP address of the client (in this case, the workstation). However, there is no logon session identifier because the domain controller handles authentication – not logon sessions.   Authentication events are just events in time; sessions have a beginning and an end.  In Windows, each member computer (workstation and servers) handles its own logon sessions.

When the domain controller fails the authentication request, the local workstation will log 4625 in its local security log noting the user’s domain, logon name and the failure reason.  There is a different failure reason for every reason a Windows logon can failure, in contrast with the more general result codes generated by the Kerberos domain controller events.

If authentication succeeds and the domain controller sends back a TGT, the workstation creates a logon session and logs event ID 4624 to the local security log.  This event identifies the user who just logged on, the logon type and the logon ID.  The logon type specifies whether the logon session is interactive, remote desktop, network-based (i.e. incoming connection to shared folder), a batch job (e.g. Scheduled Task) or a service logon triggered by a service logging on.  The logon ID is a hexadecimal number identifying that particular logon session. All subsequent events associated with activity during that logon session will bear the same logon ID, making it relatively easy to correlate all of a user’s activities while he/she is logged on.  When the user finally logs off, Windows will record a 4634 followed by a 4647.  Event ID 4634 indicates the user initiated the logoff sequence, which may get canceled.  Logon 4647 occurs when the logon session is fully terminated.  If the system is shut down, all logon session get terminated, and since the user didn’t initiate the logoff, event ID 4634 is not logged.

While a user is logged on, they typically access one or more servers on the network.  Their workstation automatically re-uses the domain credentials they entered at logon to connect to other servers.  When a server receives a logon request – (for example, when a user tries to access a shared folder on a file server), the user’s workstation requests a service ticket from the domain controller which authenticates the user to that server.  The domain controller logs 4769,  which is useful because it indicates that user X accessed server Y; the computer name of the server accessed is found in the Service Name field of 4769.  When the workstation presents the service ticket to the file server, the server creates a logon session and records event ID 4624 just like the workstation did earlier but this time logon type is 3 (network logon).  However as soon as the user closes all files opened during this network logon session, the server automatically ends the logon session and records 4647.  Therefore, network logon sessions typically last for less than a second while a file is saved, unless the user’s application keeps a file open on the server for extended periods of time.   This results in the constant stream of logon/logoff events that you typically observe on file servers and means that logon/logoff events on servers with logon type 3 are not very useful.  It is probably better to focus on access events to sensitive files using object access auditing.

Additional logon/logoff events on servers and authentication events associated with other types of user activity include:

• Remote desktop connections
• Service startups
• Scheduled tasks
• Application logons – especially IIS based applications like SharePoint, Outlook Web Access and ActiveSync mobile device clients

These events will generate logon/logoff events on the application servers involved and Kerberos events on domain controllers.

Also occurring might be NTLM authentication events on domain controllers from clients and applications that use NTLM instead of Kerberos.  NTLM events fall under the Credential Validation subcategory of the Account Logon audit category in Windows.  There is only event ID logged for both successful and failed NTLM authentication events.

A user leaves tracks on each system he or she accesses, and the combined security logs of domain controllers alone provide a complete list every time a domain account is used, and which workstations and servers were accessed.  Understanding Kerberos and NTLM and how Windows separates the concepts of logon sessions from authentication can help a sys admin to interpret these events and grasp why different events are logged on each system.

See more examples of the events described in this article at the Security Log Encyclopedia.