Monitoring logonsThe Windows logging system was never designed for ease of use. Depending on the audit settings, the information that is logged is rich and can meet the needs of any forensic investigation, but at the same time is cryptic and insufficiently documented. Events are logged in high volumes and support for managing these records is limited within the operating systems themselves.

This is why simple pain points, such as monitoring access to computers or resources, are difficult tasks for Windows admins, but, at the same time, are critical to comply with security best practices, industry standards, legal requirements and to ensure the health of the IT infrastructure. This article is not a deep-dive into the Windows logging system, however, I will provide information that can help admins build structure and consistency when it comes to monitoring access to Windows computers and resources.

Monitoring logon activity – “What’s in it for me?”

A common misconception is that logon events are only useful for identifying failed attempts, potentially impacting the security of the IT environment. However, there is value in monitoring successful logon attempts as well.

a) Monitoring success

While monitoring successful logons can give information on user activity, as part of the business process, and at the same time provide actionable information in terms of productivity, it may also give information on activity that breaches company policies with security repercussions. For example, logons of users outside operational time, or concurrent logons to many resources by the same user, may indicate a potentially dangerous situation which requires further investigation. In addition, the activity of users with elevated privileges, such as admins, needs to be monitored as part of security best practices and legal compliance.

Such events can be determined and managed using a log management tool capable of collecting the relevant information, and categorizing it according to pre-defined (user-defined) normal operational times. Additionally, the log management tool should be able to determine users with administrative privileges and categorize their activity accordingly. This is no easy task in Windows environments, as user names do not give an indication of their group membership, and even if it did, or other methods were used to establish group membership, the privileges may have changed in the time the user creating an action that triggers the event, and the log management tool collecting information and assessing the user’s privileges. So it is important to use a tool able to accurately determine user privilegesat the time when the event caused by a user’s actions was logged.

b) Monitoring failure

Most people regard the monitoring of failed logons as beneficial because it pinpoints instances of users mistyping their passwords, or at most an indication of unauthorized attempts to access computers and resources. However, there are other ways in which monitoring for failure logons can help an organization:

  • Failed logons by service accounts may indicate the presence of malware, if the service does not belong to an authorized application
  • Failed logons by service accounts, when the service belongs to an authorized application, or plays a role in the network infrastructure, may indicate downtime: if a legitimate service cannot logon, then it cannot do its job either
  • Failed logons by computer accounts may indicate problems in the network environment configuration, IPSec policy or authentication mechanisms all with the potential of causing activity disruptions
  • Multiple failed logons over a short period of time may signal automated brute force attacks, which, with inadequate account lockout policies, may lead to successful penetration
  • Simple failed logons to a print server may indicate people cannot use the printer.

Hence monitoring failed logons not only yields benefits from the security perspective, but from an IT management perspective as well. When this is done using log management tools capable of identifying scenarios similar to the above, it is a very effective way of keeping abreast with what is happening on the network.

First things first – Audit policy

Any monitoring attempt based on Windows security events should start from the audit policy, because it regulates the amount and type of events being logged. So the first thing an admin needs to know (or find out) is “what is the audit policy configuration I need, in order to get the info I want”. In our case, there are two audit policies which are related to computer access: “Audit account logon events” and “Audit logon events”. Both have names which are obviously related to our task, but there is no immediate information on what they mean, and what the difference between them is. Microsoft TechNet explains the difference here:

“Audit account logon events” cause the system to log security events whenever a user account logging on/off different machines is validated by the machine where the policy is configured. This means that you need to enable this setting if you want to audit the logon activity of users belonging to this machine, on other machines in the environment. The only scenario where a machine is used to validate credentials for accessing other machines, is the domain environment, where the Domain Controller or Active Directory Authentication Proxy is used to validate user accounts. This policy should be enabled on such servers only, and will record information in the “Account logon” category.

“Audit logon events” causes the system to log security events whenever a user account logs onto the machine where the policy is configured. This setting should be enabled on any machine that you want to monitor access to, and will record information in the “logon/Logoff” category.

Where to look for events

There are a couple of key variables that are very important when it comes to monitoring access to computers, both in terms of what is being logged, and where. First is the type of environment (Domain vs. Workgroup), and the second is the type of authentication being used (Kerberos vs. NTLM, typically on Windows systems). Depending on various combinations of the two variables, you need to look for security events in different places.

a) Windows workgroups

In Windows workgroups, each machine functions as a standalone entity, and the only security database which is relevant, is the local one. Usually the authentication package being used for accessing local machines is NTLM. Hence, the task of monitoring for logon events is reduced to monitoring events on the local machine alone. This means it is easier to achieve results because the volume of events to look for is smaller, and is available in one place: the security log of the machine being monitored. Additionally, NTLM, as an authentication package, delivers more straightforward, less cryptic information in the logs. You do not need to know how NTLM works under the hood in order to make heads or tails from the information it logs.

In order to monitor logon activity in Windows workgroups, it is sufficient to enable auditing for the “Audit logon events” category on every machine, and monitor the security log for events in this category.

b) Windows domains

In Windows domains, machines are centrally-managed and there is a security hierarchy and a security database hosted at domain level on the domain controller(s). This means that it is possible to have a domain user account which can be granted access to machines in the domain. In this case, the domain user account is automatically made a member of the local user accounts on the machines in the domain. Consequently, there are three distinct situations which may occur:

  • User logs on a member machine using a domain account: in this case, the Domain Controller validates the account, and, depending on the authentication package being used, it generates security events in the “Account Logon” category, in the security log of the Domain Controller itself. In addition, since domain accounts are members of the local user groups on the machines belonging to the domain, the logons will ALSO be recorded on the member machines, as local users logging on, with information in their security log, in the Logon/Logoff category.
  • User logs on a member machine using a local user account: in this case, the Domain Controller will have no trace of this activity, and the information will be logged only in the security log of the member machine, in the Logon/Logoff category.
  • User logs on a member machine using a domain account, and the Domain Controller is not available (i.e. logon to a laptop, part of a domain, while it is off premises): in this case the authentication uses the local cache to decide whether to grant or deny access, and it will log events in the “Logon/ Logoff” category, in the local security log, with a particular value of the “Logon type” field.

Kerberos is the default as authentication protocol for Windows Domains, starting with Windows 2000, and it involves a more elaborate authentication process than the NTLM protocol. Depending on the case, both the user and the machine it connects from (when accessing member machines over the network) may need to authenticate with the domain controller via authentication tickets and service tickets. Additionally, the process includes a pre-authentication stage, designed to provide more granularity in terms of reasons, when authentication fails. Hence, the information recorded by the Domain Controller when users log on using domain accounts, is different in structure and contents, than the information being logged locally on each machine, as a local user account logs on. More information on Kerberos authentication and the information it records to the security log:

In order to monitor logon activity in a Windows domain, you need to monitor the following:

  • Domain Controller security log, for events in the “Account logon” category, in order to determine the logon activities of domain user accounts; this includes the local logons on the Domain Controller (local Domain Controller accounts are domain accounts)
  • Member machine security log, for events in the Logon/Logoff category, in order to determine the activity of user accounts local to the member machine, particularly the local user accounts that do not map a domain account.

Relevant Event IDs

The relevant event ids vary with the operating system of the machines involved in the authentication process, as well as the authentication package being used and network environment. There are two main cases explained below:

a) Logging on using a local user accounts on domain member machines, or workgroup machines

Relevant Event ID

b) Logging on using a domain account in a Windows domain, including local access to Domain Controller

Relevant event iD2

Logon types

Logon types are important in order to determine how the user account is logging on to a resource, and this information is being logged in logon/logoff events: There are 14 logon types, each being useful to determine various situations (0 and 1 are system reserved):

Logon Types

Logon events can tell you a great deal about users, computers and applications, so it is worth investing the time to learn more about events and the benefits for the admin. While they play a key role in any security monitoring strategy, they also bring value for IT management strategies designed to increase uptime and productivity and contribute to the overall effort of keeping IT systems running and secure.

Get your free 30-day GFI LanGuard trial

Get immediate results. Identify where you’re vulnerable with your first scan on your first day of a 30-day trial. Take the necessary steps to fix all issues.