Security, et al

This month I’m going to zero in on a specific area of audit logging that creates no end of confusion, and that is the difference between 2 categories in the Windows security log: Account Logon events and Logon/Logoff events.  These 2 categories are related but distinct and their names contribute to the confusion.  Let’s start by calling Account Logon events what they really are – authentication events.  I wish Microsoft had named the Account Logon category Authentication; it would have helped a lot. The way I remember it is, “the A in Account Logon is for Authentication.”

That being said, what is the difference between authentication and logon?  In Windows, when you access the computer in front of you or any other Windows computer on the network you must first authenticate and then you obtain a logon session on that computer.  Authentication is a point in time event.  A logon session has a beginning and end.  So are authentication events simply a duplicate of logon events?  No, and the reason is that authentication may take place on a different computer than the one you are logging into. 

Workstation Logons

Let’s start with the simplest case.  You are logging onto at the console (aka “interactive logon”) of a standalone workstation – meaning it is not a member of any domain – in fact let’s say it’s not even connected to a network.  The only type of account you can logon with in this case is a local user account defined in Computer Management \ Local Users and Groups.  You don’t hear the term much anymore but local accounts are the same thing as a SAM account.  In this case both the authentication and logon occur on the very same computer because we simply logged on to the local computer using a local account.  Therefore you will see both an Account Logon event (680/4776) and a Logon/Logoff (528/4624) event in its security log.  Note in this article I’ll always note the 3 digit Windows 2003 event followed by the 4 digit Windows 2008 event.

Now let’s make this workstation a member of a domain.  At this point it’s possible to authenticate to this computer using a local account or a domain account – or, for that matter, a domain account from any domain that this domain trusts.  We’ve already discussed what happens when you logon with a local account so let’s logon with a domain account.  Since the user specifies a domain account, the local workstation can’t perform the authentication because the account (and its password hash) isn’t stored locally.  So the workstation must request authentication from a domain controller via Kerberos.  So this time, the authentication event (672/4768) is logged on which ever domain controller handles the authentication request from the workstation.  Once the domain controller tells the workstation that the user is authentic the workstation proceeds with creating the logon session and a records a logon event (528/4624) in its security log. 

What if we logon to the workstation with an account from a trusted domain?  In that case one of the domain controllers in the trusted domain will handle the authentication and log 672/4768 there, with the workstation logging 528/4624 the same as above. 

In all such “interactive logons”, when you finally logoff, the workstation will record a “logoff initiated” event (551/4647) followed by the actual logoff event (538/4634).  You can correlate logon and logoff events by Logon ID which is a hexadecimal code that identifies that particular logon session.

Accessing Member Servers

After logging on to a workstation you normally re-connect to shared folders on a file server.  What gets logged in this case?  Remember, whenever you access a Windows computer you must obtain a logon session – in this case a “network logon” session.  Intuitively you might assume that the logon session begins when you connect to the share and then ends when you disconnect from it – usually when logging off your local workstation.  Unfortunately though, Windows servers only keep network logon sessions alive for as long as you have a file open on the server.  This accounts for why you see repeated logon/logoff events on Windows file servers by the same user throughout the course of the day.  With network logons, Windows 2003 logs 540 instead of 528 while Windows 2008 logs 4624 for all types of logons. 

When you logon at the console of the server the events logged are the same as those with interactive logons at the workstation as described above.  More often though, you logon to a member server via Remote Desktop.  In this case the same 528/4624 event is logged but the logon type indicates a “remote interactive” (aka Remote Desktop) logon.  I’ll explain logon types next.

Something we often need to know, when looking at logon events is what type of logon are we dealing with?  Is this an interactive logon at the console of the sever indicating the user was physically present or is it a remote desktop logon.  For that matter the logon could be associated with a service starting or a scheduled task kicking off.  In all such cases you will need to look at the Logon Type specified in the logon event 528/540/4624.  A full list of Logon Types is provided at the provided links for those events but in short:

Events at the Domain Controller

When you logon to your workstation or access a shared folder on a file server, you are not “logging onto the domain”.  There’s no such concept.  Each Windows computer is responsible for maintaining its own set of active logon sessions and there is no central entity aware of all everyone who is logged on somewhere in the domain.  After servicing an authentication request, the domain controller forgets about you; it doesn’t know how you were logging (console, remote desktop, network, etc) nor when you logoff. 

“But wait,” you might say “I see logon events on the domain controller, not just authentication events, whenever a user logs on to their workstation” and then periodically after that.   OK, that’s true: on domain controllers you often see one or more logon/logoff pairs immediately following authentication events for the same user.  But these logon/logoff events are generated by the group policy client on the local computer retrieving the applicable group policy objects from the domain controller so that policy can be applied for that user.  Then approximately every 90 minutes Windows refreshes group policy and you see a network logon and logoff on the domain controller again.  These network logon/logoff events don’t tell you much, I regard them usually as noise.  In forensic situations they could give you a rough idea of how long the user was logged on since as long as the user remains logged on group policy will refresh about every 90 minutes.  The other possibly useful thing about these group policy related logon/logoff pairs is that they help you infer that the preceding authentication events for the same user were in conjunction with an interactive or remote desktop logon as opposed to a service or scheduled task logon. 

What about the other service ticket related events seen on the domain controller?  That requires an in-depth discussion of Kerberos and how it’s implemented which is beyond the scope of this article.  Basically, after your initial authentication to the domain controller which logs log 672/4768 you also obtain a service ticket (673, 4769) for every computer you logon to including your workstation, the domain controller itself for the purpose of group policy and any member servers such as in connection with shared folder access.  Then as computers remain up and running and users remain logged on, tickets expire and have to be renewed which all generate further Account Logon events on the domain controller.

The Facts: Good, Bad and Ugly

Both the Account Logon and Logon/Logoff categories provide needed information and neither can replace the other – you need both.  And, ideally, you really need both categories of events from all your computers – including your workstations.  Here’s a number of important facts you need to understand, and… well… accept. 

1.       To determine definitely how a user logged on you have find the logon event on the computer where the account logged on.  You can only make some tenuous inferences about logon type by looking at the domain controller and that requires analyzing multiple events. 

2.       To determine when a user logged off you have to go to the workstation and find the “user initiated logoff” event (551/4647).

3.       To correlate authentication events on a domain controller with the corresponding logon events on a workstation or member server there is no “hard’ correlation code shared between the events.  Folks at Microsoft have suggested the Logon GUID field in these events would provide that but my research and experiments indicate that unfortunately the GUIDs are either not supplied or do not match.  So to make that correlation you basically have to dead reckon based on time, computer names and user account names. 

4.       Account Logon events on domain controllers are great because they allow you to see all authentication activity (successful or failed) for all domain accounts.  Remember that you need to analyze the security logs of all your domain controllers – security logs are not replicated between DCs. 

5.       Account Logon events on workstations and member servers are great because they allow you to easily pick out use of or attacks against local accounts on those computers.  You should be interested in that because using local accounts is bad practice and bad guys know they tend to be more vulnerable than domain accounts.  But, you don’t have to use Account Logon to detect logon attempts on local accounts; you can use Logon/Logoff events if you know what you are doing.  When viewing a Logon/Logoff event compare the domain name in the event details to the computer name that generated the event; if they match you are looking at a local account logon attempt – otherwise the domain name field with reflect some domain.  So can you survive with only enabling Logon/Logoff events on member servers and workstations?  I suppose so.

6.       Logon/Logoff events are a huge source of noise on domain controllers because every computer and every user must frequently refresh group policy.  If you disable this category on domain controllers what will you lose?  You will lose some visibility into logons at the domain controller itself such as when an admin logs on at the console, via remote desktop or a service or scheduled task starts up.  In all cases Account Logon events will still be logged but see points 1 and 2 above.

7.       Basically, successful network logon and logoff events are noise on domain controllers and member servers because of the amount logged.  Unfortunately you can’t just disable successful network logon/logoff events without also losing other logon/logoff events for interactive, remote desktop, etc.  My old adage is: “you can’t configure the noise out of the Windows security log” – that’s the job of your log management / SIEM solution. 

So that’s the difference between Account Logon (i.e. authentication) and Logon/Logoff events.  All things considered, I’d like to see both categories enabled on all computers ideally.  I haven’t seen these events create a noticeable impact on the server but the amount of log data might exceed your log management / SIEM solution’s current capacity.  If you can’t afford to collect workstation logs, I still suggest enabling these 2 categories on workstations and letting the log automatically wrap after reaching 100MB or so.  Chances are the data will be there if you need it for forensic purposes.