Powerful threat prediction, prevention, detection, and response along with compliance in a scalable, simple managed solution.
All-in-one networking solution that combines network connectivity, agility, security, and compliance in an affordable managed solution.
Accelerate business growth through our award-winning partner program.
9 min read
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.
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.
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:
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.
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.
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.
Download Whitepaper Now!
7 min read
5 min read
4 min read