Security, et al

This article was first published in EventTracker’s EventSource Newsletter: http://www.eventtracker.com/newsletters/following-a-users-logon-tracks-throughout-the-windows-domain/

In this article, I’ll show you the security events that 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.  You can see examples of all the events described in this article at the Security Log Encyclopedia.

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 OK, 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 – the workstation in this case.  Note that there is no logon session identifier though.  This is 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 possible reason a Windows logon can failure – in contrast with the more general result codes generated by the Kerberos domain controller events described above. 

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 is a number that 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 the activity of a user while 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.  Once the logon session fully terminates you get logon 4647.  If the system is shut down all logon session get terminated and since the user didn’t initiate the logoff, no event ID 4634 is 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 – such 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 that authenticates the user to that server.  The domain controller logs 4769 which is useful because it tells you 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.

You will see additional logon/logoff events on servers and authentication events associated with other types of user activity such as:

• 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. 

You may also see 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.

As you can see, a user leaves tracks on each system they access and the combined security logs of your domain controllers alone provide a complete list of 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 really helps you interpret these events and grasp why different events are logged on each system.