An area of audit logging that is often confusing is the difference between two categories in the Windows security log: Account Logon events and Logon/Logoff events.  These two categories are related but distinct, and the similarity in the naming convention contributes to the confusion. 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 obtain a logon session for that computer. A logon session has a beginning and end. An Account Logon event  is simply an authentication event, and is a point in time event.  Are authentication events a duplicate of logon events?  No: the reason is because authentication may take place on a different computer than the one into which you are logging.

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).  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 and SAM accounts are the same thing.  In this case both the authentication and logon occur on the very same computer because you 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.

If the workstation is 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  a domain account from any domain that this domain trusts. When the user logs on 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 aren’t stored locally.  So the workstation must request authentication from a domain controller via Kerberos.  An 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 authenticated, 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”, during 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 can typically 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.  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 this is not the case: Windows servers only keep network logon sessions alive for as long as you have a file open on the server.  This accounts 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.

When looking at logon events we need to consider 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”. Each Windows computer is responsible for maintaining its own set of active logon sessions and there is no central entity aware of everyone who is logged on somewhere in the domain.  After servicing an authentication request, the domain controller doesn’t maintain information about how you were logging (console, remote desktop, network, etc) or when you logged off.

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 are little more than noise.  In forensic situations, they provide an estimate of how long the user was logged on (as long as the user remains logged on group policy will refresh about every 90 minutes), and can help to 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? 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 are not fungible:  both are distinct and necessary.  Here are some important facts to understand, and accept about authentication and logon/logoff events.

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. Successful network logon and logoff events are little more than “noise “on domain controllers and member servers because of the amount of information logged and tracked.  Unfortunately you can’t just disable successful network logon/logoff events without also losing other logon/logoff events for interactive, remote desktop, etc.  Noise can’t be configured out of the Windows security log; that’s the job of your log management / SIEM solution.

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.