Chapter 5
Logon/Logoff Events

Logon/Logoff events in the Security log correspond to the Audit logon events policy category, which comprises nine subcategories. As the name implies, the Logon/Logoff category’s primary purpose is to allow you to track all logon sessions for the local computer. As we discussed earlier, there is a subtle difference between authentication events, which are covered by the Account Logon events discussed in the previous chapter, and logon events, which track access to a given computer. No matter which type of account (i.e., domain or local) or which type of logon session (e.g., interactive, network, remote desktop) the Logon/Logoff category generates a logon event and a logoff event at the beginning and end of each logon session. Those two events are logged by the Logon and Logoff subcategories.

As for the other seven subcategories, some of them have nothing to do with logon or logoff activity. You’ll see some events that allow you to track the use of Terminal Services, screensaver logons, and so forth. In our opinion, the three IP Security (IPsec)-related subcategories and the Network Policy Server subcategory belong somewhere else. Windows provides IPsec support for authentication, encryption, and integrity at the IP-packet level. Network Policy Server a role that can be added to Server 2008, as well as the Microsoft’s RADIUS Server role. It includes what was previously known as Internet Access Server (IAS) and Network Access Protection (NAP). Regardless, Microsoft has done a lot to help you track every avenue that is used to access the server.

Logon/Logoff Subcategories	Comment
Logon	Use logon ID to correlate other events
Logoff	Not always present
Account Lockout	Not used (see Chapter 4 for lockout events)
IPsec Main Mode	Establish Internet Key Exchange (IKE)
IPsec Quick Mode	IPsec security associations
IPsec Extended Mode	Multiple authentications
Special Logon	Admin type logons
Other Logon/Logoff Events	Screensaver, Remote Desktop. etc.
Network Policy Server	Combination of IAS and NAP

Logon Events

Whether a user tries to log on by using a local SAM account or by using a domain account, the Logon subcategory records the attempt on the system to which the user tried to log on as shown below. When the user logs on to a workstation’s console, the workstation records a Logon/Logoff event. When you access a Windows server on the network, the relevant Logon/Logoff events appear in the server’s Security log. So, although account logon events that are associated with domain accounts are centralized on DCs, Logon/Logoff events are found on every system in the domain. The diagram below demonstrates the event IDs that are recorded when a user initially logs on interactively to a workstation and accesses a shared folder on a file server. These events are the same whether the user logs on with a local account or a domain account.

How do you link a successful logon event to its corresponding logoff event? You use the Logon ID field in the New Logon section. Do not confuse this with the Logon ID field in the Subject section; the latter displays the logon ID (0x3e7 in our example below) of the computer or server on which the event is recorded. The logon ID (0xe9cd0 in our example) is a unique number between system restarts (on that system) that identifies a particular logon session.

Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 11/3/2008 11:47:58 AM Event ID: 4624 Task Category: Logon Level: Information Keywords: Audit Success User: N/A Computer: Lab2008.acme.ru Description: An account was successfully logged on. Subject:                 Security ID:                         SYSTEM                 Account Name:                    LAB2008$                 Account Domain:                 ACME                 Logon ID:                           0x3e7   Logon Type:                                         2   New Logon:                 Security ID:                         ACME\Administrator                 Account Name:                    Administrator                 Account Domain:                 ACME                 Logon ID:                           0xe9cd0                 Logon GUID:                      {b8efeca1-0319-d60e-91bb-f09a513d65bf}   Process Information:                 Process ID:                         0xbfc                 Process Name:                    C:\Windows\System32\winlogon.exe   Network Information:                 Workstation Name:                LAB2008                 Source Network Address:       127.0.0.1                 Source Port:                         0   Detailed Authentication Information:                 Logon Process:                     User32                 Authentication Package:        Negotiate                 Transited Services:                -                 Package Name (NTLM only):  -                 Key Length:                          0

You might think by looking for a subsequent instance of event ID 4634 that has the same logon ID as an instance of event ID 4624, you can show when a user logged on and logged off. However, Windows doesn’t log event ID 4634 in the way you’d expect, especially for network logons.

Let’s discuss interactive logons first. When Sue logs on to her workstation, Windows logs event ID 4624 with logon type 2 and the logon ID for the logon session. When Sue logs off, Windows logs event ID 4634 with the same logon ID. But what if the system crashes or is unceremoniously powered down before Sue logs off? When Windows restarts, it might reconstruct the fact that Sue was logged on and record an instance of event ID 4634. Taken literally, the event log won’t make sense because you’ll see a system restart followed by a logoff. Logging that artificial instance of event ID 4634 is a bit of a formality. At any rate, tracking user logoffs in a workstation's Security log is pretty easy.

Tracking network-session logoffs in a server’s Security log is another story. When a user maps to a shared folder, the server logs event ID 4624 with the logon ID of the logon session. However, if the user opens no files and no other activity occurs on the network connection, the server closes the logon session after a period of time to conserve resources—even if the user remains connected to that share. This server-initiated logoff is invisible to the user because when he or she finally accesses a file, the server opens a new logon session.

DC Security logs contain many Logon/Logoff events that are generated by computer accounts as opposed to user accounts. As with computer-generated account logon events, you can recognize these logon and logoff events because the Account Name field in the New Logon section will list a computer name followed by a dollar sign ($). You can ignore computer-generated Logon/Logoff events.

The Logon Process description field in the Detailed Authentication Information section identifies the Windows process that submitted the logon request. A logon process collects identification and authentication information and then uses Local Security Authority services to log on users. Because different logon processes handle specific logon types and scenarios, the logon process name can help you fill in some gaps in the information provided by Logon/Logoff events.

For instance, you might see event ID 4624 with logon type 3 and Bob’s username. Does that mean that Bob connected to a Windows resource such as a shared folder or that he accessed a Web page on the server? If the logon process is “advapi,” you can determine that the logon was a Web-based logon: IIS processes logon requests through the advapi process. If the logon was to a Windows resource and authenticated via Kerberos, the Logon Process field would list “Kerberos.” Generally, the Logon Process field provides a hint at how the user tried to access the system: at its console, through Server Message Block (SMB) or Common Internet File System (CIFS) for shared-folder access, or through IIS. Some logon processes are authentication-protocol specific as shown in the chart below.

Process	Explanation
Winlogon	Windows Logon Process
Schannell	Secure connection such as SSL
KSecDD	Kernel Security Device Driver
Secondary Logon Service	(runas)
IKE	Internet Key Exchange
HTTP.SYS	Kernel for Web server
SspTest
dsRole	Directory Service function
DS Replication	Directory Service function
CredProvConsent	(user account control)
NtLmSsp	Might also be anonymous authentication

The Authentication Package description field is closely related to the Logon Process and Process Information fields. These fields identify the DLL that was used to handle the actual authentication of the logon attempt. Together, Logon Process and Authentication Package shown below provide valuable information about where and how a user attempted to log on to the system. This information is important because there are so many ways to access a Windows computer.

Package	Explanation
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 or NTLM	NT LanManager, used for logon with local account and others
Wdigest	Digest authentication, usually through IIS
Microsoft Unified Security Protocol Provider or Schannel.dll	TLS/SSL authentication usually has to do with IIS Web content that requires SSL and authentication
Kerberos	Kerberos (default authentication)
Negotiate	Kerberos or NTLM, depending on client capability

Logon/Logoff events aren’t a good option for tracking domain account authentication or for detecting attempts to use local SAM accounts to access computers. However, they do provide some information that would otherwise be unavailable.

First and foremost, Logon/Logoff events on a system give you a complete record of all attempts to access that computer, regardless of the type of account used. Second, these events reveal the type of logon, which you can’t determine from Account Logon events. Logon/Logoff events also provide the IP address of the client computer, which is useful information for NTLM-based logons because NTLM Account Logon events don’t provide the IP address. An example of the first part of a logon event is in Error! Reference source not found. . (When you copy an event, Microsoft also includes an attempt to explain parts of the event and presents the info in XML format.) Both network and interactive logons are recorded by event ID 4624.

The logon type fields shown in the chart below are useful because they help you to identify how the user logged on. Logon type 2 indicates an interactive logon at the console. Type 3 indicates a network logon. You’ll likely see a lot of these two types; sessions can time out or be torn down and be re-established by a server without the user being aware of it; most connections to a server will be type 3.

Logon Type	Description
2	Interactive (logon at keyboard and screen of system)
3	Network (i.e., connection to shared folder on this computer from elsewhere on network)
4	Batch (i.e., scheduled task)
5	Service (service startup)
7	Unlock (i.e., unattended workstation with password-protected screen saver)
8	NetworkCleartext (i.e., logon with credentials sent in clear text; most often indicates a logon to IIS with basic authentication)
9	NewCredentials (e.g., RunAs, mapping a network drive with alternate credentials; does not seem to show up in any events) If you want to track users attempting to logon with alternate credentials see event ID 4648.
10	RemoteInteractive (e.g., Terminal Services, Remote Desktop, Remote Assistance)
11	CachedInteractive (logon with cached domain credentials such as when logging on to a laptop when away from the network)

So now you know who logged on and how. Knowing where the user logged on would also be useful; you can use the identified workstation name and IP address to track down that information. Keep in mind that in a Dynamic Host Configuration Protocol (DHCP) environment, computer names and IP addresses can change from time to time.

Two other events appear under the Logon subcategory. Logon failures will appear as event ID 4625.

In earlier Windows versions, several different events were used for failures. Event ID 4625 merges those events and indicates a failure code that will help to identify the reason for the failure. Microsoft did a good thing by adding the Failure Reason section to Windows Server 2008 events. This section provides some of the translation for you, but you can still earn your salt by becoming familiar with all these codes which are shown below.

Status and Sub Status Codes	Description
0xC0000064	user name does not exist
0xC000006A	user name is correct but the password is wrong
0xC0000234	user is currently locked out
0xC0000072	account is currently disabled
0xC000006D	reason not specified (Sub status may provide more information)
0xC000006F	user tried to logon outside his day of week or time of day restrictions
0xC0000070	workstation restriction
0xC0000193	account expiration
0xC0000071	expired password
0xC0000133	clocks between DC and other computer too far out of sync
0xC0000224	user is required to change password at next logon
0xC0000225	evidently a bug in Windows and not a risk

Finally, this subcategory includes event ID 4648 (A logon was attempted using explicit credentials), which will appear in a variety of situations, such as when RunAs is invoked or when a scheduled task runs.

Logoff Events

Ostensibly, the Logoff subcategory should also provide the ability to track the logon session that relates to a logoff (event ID 4634). Unfortunately, the value of the Logoff subcategory is questionable at best; these events don’t always tell you exactly when a particular user logged off. For example if a dirty shutdown occurs, a logoff event will appear only during the subsequent startup, when the operating system realizes that the user is no longer connected.

To compensate for the problems with using event ID 4634 to accurately track logoffs, Windows also logs event ID 4647 (A user initiated a logoff). This event indicates that the user (rather than the system) started the logoff process. Event ID 4634 usually occurs a couple of seconds later. Event ID 4647 is probably a better event to use for tracking the termination of interactive logon sessions.

Account Lockout

No events are associated with the Account Lockout subcategory. You’ll find lockout events under User Account Management subcategory discussed in Chapter 8.

IPsec Main Mode, IPsec Quick Mode, IPsec Extended Mode

These three subcategories will generate many events, so you might want to consider turning on this auditing only for troubleshooting IPsec or firewall issues. IPsec uses packet filtering and encryption to enhance security and provides authentication, integrity checking, and optional encryption at the packet level. IPsec can provide a defense against a network attack by untrusted computers. A security association (SA) is first established with IPsec Main Mode (also known as Phase 1); if this subcategory is enabled, the events will appear in the audit log. After Phase 1 is used, Quick Mode (aka Phase II) negotiation takes place. The negotiation of Quick Mode is protected by the Main Mode encryption and filtering rules. In Quick Mode, two SAs are used: one for incoming packets and one for outgoing packets. With Extended Mode, another round of authentications can be performed. Multiple authentication is part of IPsec support for Network Access Protection (NAP). See the article "IPsec and Group Policy: A Stronger Defense" for an in-depth description. The events tell you whether negotiation and authentication is successful and SAs are established, or whether negotiation fails.

Special Logon

The Special Logon subcategory contains only one event: event ID 4672, which indicates that a highly privileged user has logged on. This event lets you know whenever an account that is assigned any "administrator-equivalent" user rights logs on. For instance, you will see event ID 4672 in close proximity to logon events (event ID 4624) for administrators because administrators have most of these administrator-equivalent rights. This right is a useful for detecting any "super user" account logons. The right also is logged for any server or application accounts that log on as a batch job (scheduled task) or system service. See the Logon Type field in event ID 4624. You can correlate event ID 4672 to event ID 4624 by matching the Logon ID.

Note: "User rights" and "privileges" are synonymous terms that are used interchangeably in Windows. Administrator-equivalent rights are powerful authorities that allow you to circumvent other Windows security controls. Most administrator-equivalent privileges are intended for services and applications that interact closely with the operating system. With just a few exceptions, most administrator-equivalent privileges neither need nor should be granted to end user accounts.

Other Logon/Logoff Events

The Other Logon/Logoff Events subcategory contains events that are associated with screensaver, console locking, and Remote Desktop connections. If your organization has a lockout policy—and it should—these events can enable an auditor to see whether interactive and remote Terminal Server sessions are actually being locked out when unattended.

Network Policy Server

The Network Policy Server subcategory logs events associated with Windows's Network Policy Server, which provides Network Access Policy functionality for Windows networks including IPsec, 802.1x, quarantine and more. You can configure granular auditing for this and other subcategories by using Auditpol.

Bottom Line

Logon/Logoff events correspond to the Audit logon events policy category and can help you track the local computer’s logon sessions. Although not the best option for tracking domain account authentication, these events can provide information you won’t be able to obtain elsewhere.