Chapter 3
Understanding Authentication and Logon

You might have noticed that Windows 2000 (and later) has two audit policies that mention logon events: Audit account logon events and Audit logon events. Windows NT had only Audit logon events. But by itself, Audit logon events has limited value because of the way that Windows handles logon sessions.

When you use a domain account to log on to a computer, you might expect the event to be logged on the DC. In reality, the logon occurs on the workstation or server that you are accessing. Therefore, the event is logged in that computer’s Security log—if Audit logon events is enabled on that system. Without DCs logging authentication activity, completing an audit trail of domain-user logon activity is impossible: You would need to collect the Security logs from every workstation and server on your network!

To remedy this issue, Microsoft added the Audit account logon events policy in Windows 2000 and later. Leave it up to Microsoft to give an important new feature a confusing name. Audit account logon events would be better named Audit authentication events. In Windows, authentication and logon are related but ultimately separate activities that can (and often do) take place on separate systems.

To effectively use these two audit policies, you need a complete understanding of how the Windows authentication and logon processes work. You also need to know the difference between local and domain accounts and how each affects the audit process. In this chapter, we’ll cover both issues in detail before looking at Audit account logon events and Audit logon events in subsequent chapters.

Local and Domain Accounts

Windows supports two kinds of user accounts: domain accounts and local accounts as shown below. Local accounts are stored in the SAM of member servers and workstations and are authenticated by the local system. Domain accounts are stored in AD and are authenticated by DCs. Because of the associated maintenance problems, avoiding the use of local accounts is often best. However, attackers frequently target local accounts, so you should understand how Windows records logon attempts against those accounts.

Logon Types

Windows supports different types of logon sessions. These logon types describe the ways in which users can log on to a system—for example, through the system’s local console (interactive) or through a Remote Desktop session (remote interactive). You can use local or domain accounts with each logon type. Each logon type has a corresponding logon right that the user must possess to initiate a logon of that type. When a logon event is recorded in the event log, the number of the logon type is listed. The chart below lists the different logon types. To view or modify rights assignments, open the Local Security Policy console and drill down to Security Settings\Local Policies\User Rights Assignment.

Unfortunately, when a logon event is recorded, the Security log lists only the logon type number. The type of user account and the logon type greatly affect which computer's Security log will receive a logon event and which event IDs will be logged.

 

Logon Number	Logon Type	Example	Logon Right
0	Used only by the System account	System startup.
2	Interactive: Used to log on at the local console	User logon at console at the beginning of the day.	Log on locally
3	Network: Used to access a Windows resource (e.g., shared folder) from a system on the network	One example is when a computer has a mapped drive to another computer share.	Access this computer from the network
4	Batch Job: Used to run a scheduled task as a specified account	Task Scheduler or AT command.	Log on as a batch job
5	Service: Used to run a service as a specified account	Credentials for an account other than local service can be used for services such as Telnet.	Log on as a service
6	Proxy
7	Unlock (i.e. unattended workstation with password protected screen saver)	When a screen saver locks a system, the password must be entered to access the system at the console.
8	NetworkCleartext (Logon with credentials sent in the clear text.)	Most often indicates a logon to IIS with "basic authentication".
9	NewCredentials such as with RunAs or mapping a network drive with alternate credentials.	This logon type does not seem to show up in any events. Microsoft explanation: Allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identify, but uses different credentials for other network connections.
10	RemoteInteractive	Terminal Services, Remote Desktop or Remote Assistance.	Log on through Terminal Services
11	CachedInteractive	Logon that uses cached domain credentials (such as when logging on to a laptop when away from the network).
12	CashedRemoteInteractive	Logon that occurs when the remote system is away from the network DC.
13	CashedUnlock	Unlock that occurs when the remote system is away from the network DC.

When a user logs on interactively at a workstation, Windows uses the Log on to field to determine whether the user is trying to log on with a local or domain account.

When a user attempts a network logon, such as to a shared folder on another computer, the workstation by default reuses the credentials that the user entered when he or she initially logged on. However, the user can specify a different local or domain account.

For instance, when mapping a drive to a shared folder, a user can use the Connect using a different user name link .To specify a local account, use the format computer name\username. To specify a user account from a different domain, use the format domain\username. Logging on to a Windows system requires a similar approach as shown below.

The logon interface provides a small Help screen to remind users how to log on to another domain as shown below. (By default, only members of the Administrator group have the right to log on locally to a server.)

A service must also use an account and password to log on as shown in the "Log On" tab on in the services properties box below.

When the server is locked, the password is required to access the server.

The connection to another Windows system via Remote Desktop, Terminal Services and Remote Assistance uses Remote Desktop Protocol, or RDP as shown below. The credentials are presented to the remote server at the time of logon. This is a RemoteInteractive type.

Logon vs. Authentication

As we stated earlier, logon and authentication are separate and distinct functions in Windows. Logon occurs on the system to which a user is gaining access, whereas authentication is performed by the computer on which the user's account resides. When you use a local account to log on to a computer, that computer performs both the logon and authentication. When you use a domain account to log on to a computer, the accessed computer performs the logon but a DC in the domain that holds your user account performs the authentication.

A user can use of a domain account to log on interactively, after which the user accesses a shared folder through a network logon as shown in the diagram below. The Interactive logon at the workstation generates a Logon/logoff event in the workstation’s Security log and an Account Logon event on the DC. The Network logon generates a Logon/logoff event in the file server’s Security log and more Account Logon activity in the DC’s Security log.

A user can also use a local account to log on to the same two computers as shown below. Each computer logs both categories of events; the DC logs nothing.

As you can see, Audit account logon events is primarily a DC audit policy. However, it is also useful on member servers, for identifying attacks against local accounts. Logon attempts that use local SAM accounts should be fairly rare, if you are following best practice and using domain accounts as much as possible.

So, what is the benefit of Audit logon events, compared to Audit account logon events? As we’ll explain in Chapter 5, you can use Audit logon events to link process-tracking and object-access events to logon sessions. Audit logon events also generates more granular information about logon types and about the reason for failed logons. And Audit logon events attempts to record not only the logon event but also the logoff event of each session. (Unfortunately, logoff auditing isn’t very dependable because of the idiosyncrasies of Windows networking.)

Bottom Line

Now that we’ve clarified the differences between logon and authentication, let's dive into the nitty-gritty details of Audit account logon events and how to decode NT LAN Manager (NTLM) and Kerberos authentication events.