Monitoring and Auditing for End Systems

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft Solutions Framework

Note: This white paper is one of a series. Best Practices for Enterprise Security contains a complete list of all the articles in this series. See also the Security Entities Building Block Architecture.

Best Practices for Enterprise Security

On This Page

The Focus of This Paper
Goals of Monitoring
Monitoring Architecture
Event Monitoring
Object Monitoring
Performance Monitoring
Other Monitoring
Monitoring Utilities
References and Related Links

The Focus of This Paper

An operating system is the foundation of any useful computer system. Regardless of a specific computer's purpose—file or print server, database, messaging, or Web server—an operating system provides the basic functionality that enables an application. This paper refers to the hardware and operating system installation as the "local resources" entity.

Because a number of server vendors each provide their own functionality and methodology for monitoring their hardware platforms, this document focuses only on the operating system itself, either Microsoft Windows NT 4.0 or Microsoft Windows 2000.

Goals of Monitoring

How to Accomplish Them

The general goal of monitoring is to detect suspicious behavior by external users or employees, or malfunctions. An organization can do this directly, such as by monitoring for specific events, or indirectly, such as by watching the state of a server over time and investigating anomalous behavior.

Your security organization will have to determine its specific monitoring policy. Within this policy, you will have to determine your organization's specific monitoring goals. Some questions you will have to answer are:

  • Are you going to baseline your server's performance? If so, what counters are you going to collect and at what interval? How often are you going to take baselines?

  • What objects are you going to audit? For each class of object, which accesses are you going to audit? For each class of object, which instances are you going to audit?

  • What other kinds of events are you going to audit?

  • How are you going to manage your event logs? Are you going to use the tools Microsoft provides, write your own, or purchase a third-party system?

  • Which monitoring technologies are you going to use?

  • How much are you going to monitor? Monitoring a system has a distinct impact on system performance—the more you query or log a system's state, the more resources the system must expend on these activities.)

Monitoring Architecture

Built-in Mechanisms

Windows NT 4.0 and Windows 2000 have several built-in mechanisms that can be used for monitoring:

  • Event logging (auditing). The system itself and applications on the system can generate records of significant events.

  • Performance monitoring. The system and certain applications on the system report performance information regularly.

  • Simple Network Management Protocol (SNMP). The system supports SNMP 2.0, an industry-standard, platform-independent method of monitoring networked devices.

  • Windows Management Instrumentation (WMI). Windows 2000 includes WMI, which can be installed on Windows NT 4.0. WMI is not a monitoring service, but rather a unified management interface that integrates the various other monitoring mechanisms.

Event Logging

Event log data is reported to the Event Log service by other parts of the system or by applications running on the system. The Event Log service stores this data in .evt files in the %systemroot%\system32\config directory. The built-in logs in Windows NT 4.0 and Windows 2000 Professional are the system log, the security log, and the application log. Windows 2000 Server installations may add logs for Domain Name System (DNS) and directory services. Any application that needs to log events should register itself with the Event Log service.

Events stored in the event logs have a description field that displays text data describing the event. Typically, this is the text of an error message. Usually, only information unique to a particular instance of an event is stored with the event in the log; the text strings are stored in an event message file (usually a .dll or .exe file) that is registered with the Event Log service. If, when viewing an event, you see an error in the description field indicating that the event text is not available, you will need to register the event message file with the Event Log service on the computer at which you are trying to view the event. More information on this is available at https://support.microsoft.com/default.aspx?scid=kb;en-us;165959&sd=tech

More documentation about using the event log application programming interface (API) is available at https://msdn2.microsoft.com/en-us/library/ms994812

Performance Monitoring

Performance data is stored in the registry; however, it is usually accessed by using APIs such as the Performance Data Helper API or by using WMI. More information about the architecture of the performance monitoring system is available at https://msdn2.microsoft.com/en-us/library/d88a8ew8(VS.80).aspx

SNMP

By installing the SNMP service, you will enable the system to respond to requests from SNMP management consoles. Installing the SNMP service also adds performance counters for Internet Protocol (IP), Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), and Transmission Control Protocol (TCP). SNMP allows you to query the current state of many local resources, and also allows you to control a small number of operating system and application parameters.

Because Windows NT and Windows 2000 do not come with an SNMP management console, either a third-party console or some in-house development of such a console will probably be necessary for SNMP to be useful. However, Microsoft does provide two useful resource kit utilities, SNMPUtil, which is a command-line SNMP query utility, and SNMPMon, which is a command-line utility that can query and log SNMP counters over time and can be configured with a text file.

WMI

Windows Management Instrumentation is Microsoft's implementation of the Web-based Enterprise Management (WBEM) industry-standard management architecture, which attempts to develop a common interface for accessing management information in an enterprise environment.

WMI includes support for querying the system for information on event log, performance, and SNMP. It is easily scripted in any Windows Script Host-compatible scripting language such as Microsoft Visual Basic Scripting Edition (VBScript) or Microsoft JScript .

More information about WMI can be found at https://msdn2.microsoft.com/en-us/library/ms811552

More information about the WMI and SNMP implementations on the Windows NT and Windows 2000 platforms can be found at https://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/wmisnmp.mspx

Event Monitoring

Event Log Management

When a system is configured to collect many different kinds of events, the event logs tend to fill up quickly. Conversely, if only a few kinds of events are logged, then important information could be missed. Therefore, deciding what to log and what not to log is a complicated decision.

When deciding which event categories to log, it is important to consider the volume of events that will be generated and the utility of capturing any specific information. It is best to decide exactly what type of information you want to capture and then configure the logging mechanisms to log the minimum necessary number of events to collect that information. A "shotgun" approach—that is, turning logging up to the maximum setting—often results in a large amount of data that is ignored or discarded because there is too much to analyze or store.

Windows NT 4.0 and Windows 2000 include a utility called Event Viewer that allows the event logs to be viewed (in a filtered or non-filtered fashion), saved, and cleared. This utility also allows an administrator to control whether or not new events are allowed to overwrite old events when the log is full, and to limit the maximum size of the event logs. Neither Windows NT 4.0 nor Windows 2000 includes any utilities to centrally collect and manage event logs, although various third-party vendors sell such utilities.

Event log management is one of the most important facets of monitoring an enterprise. At the system level, a utility such as Event Viewer may be sufficient for your entire event-monitoring needs. However, when monitoring many computers across an enterprise, the amount of data collected will generally far exceed the ability of an administrator to manage, and so some central collection mechanism is generally needed.

Recommendation: Evaluate and purchase a centralized event-log management system for your enterprise. When evaluating different packages, consider both the scalability and features of the event-collection system and the quality of the query and reporting features of each package—gathering event log data in mass quantities is not useful if the analysis tools are not useful.

Another important aspect of event log management is to manage the size, location, and overwrite policy for each the event logs.

Each log has several configurable parameters:

  • Location and name of the log file. This is stored separately for each log, in a REG_EXPAND_SZ value called File, which is in the key:

    HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\<log name>

  • Maximum log file size. This can be configured in the Event Viewer application, and defaults to 512 kilobytes (KB).

  • Overwrite behavior when log is full. There are three choices: overwrite events as needed, overwrite events older than a certain number of days, and do not overwrite. If you choose to overwrite only events older than a certain number of days, you can configure the number of days.

  • Restrict guest access (Windows 2000 only). This can be used to allow only authorized users access to the event log.

Additionally, there is a system-wide setting, CrashOnAuditFail, which will cause the system to halt if the security log fills. In most cases, CrashOnAuditFail is an undesirable setting. For more information, see "How to Prevent Auditable Activities When Security Log Is Full" at https://support.microsoft.com/default.aspx?scid=kb;en-us;140058&sd=tech

If you decide to use CrashOnAuditFail, you should configure the audit log settings carefully. As of this writing, this setting has at least one outstanding problem: "STOP 0xC0000244 When Security Log Full" at https://support.microsoft.com/default.aspx?scid=kb;en-us;232564&sd=tech

Event Analysis

Events in the event log contain the following fields:

  • Date and time

  • Type: the severity of the event

  • Source: the component that logged the event

  • Category: a further subgrouping of security events

  • Event ID: a unique number identifying the event that occurred

  • User: the name of the user to which the event relates, if any

  • Computer: the machine on which the event was logged

  • Description: textual data such as error messages associated with the event

  • Data: binary data associated with the event

Of these fields, it is very important to note the event ID and the description text. The event ID is the easiest way to research the event in the Microsoft Knowledge Base, and the description text usually describes what happened in simple language. Also, the description field often contains unique information about a specific event, especially security events. If you collect events to a central database using a non-Microsoft event-collection tool, be sure to collect the description field for all security events.

For more information about event structure, see "Elements of an Event Record" at https://www.microsoft.com/technet/archive/ntwrkstn/reskit/appb_sec.mspx

Monitoring the System

Monitoring the General System

As a rule, it is a good idea to audit both success and failure events of the "System" category.

Windows uses this category to log events that affect the security of the entire system:

512  

Windows NT is starting up.  

513  

Windows NT is shutting down.  

514  

An authentication package has been loaded by the Local Security Authority.  

515  

A trusted logon process has registered with the Local Security Authority.  

516  

Internal resources allocated for the queuing of audit messages have been exhausted,  
leading to the loss of some audits.  

517  

The audit log was cleared.  

518  

A notification package has been loaded by the Security Account Manager.

If you notice any abnormalities in these events, someone could be loading a password-interception program or an unauthorized authentication package, which might not be secure.

Monitoring Audit Policy

The Local Security Authority (LSA) of a Windows NT or Windows 2000 system performs many security-related tasks for the system and is responsible for enforcement of the system's security policies (including site, domain, and organizational unit policies in Microsoft Active Directory that apply to the local machine). One of the main policies of interest when monitoring the system is the Audit policy.

The Audit policy is manipulated in User Manager in Windows NT 4.0. On computers running Windows 2000, it is manipulated in Group Policy, which can be invoked for the local machine using the Local Security Policy item in the Administrative Tools menu in the Start menu. Audit policy is located under Local Policy\Audit Policy in the tree structure. Group Policy can also be set for a domain or organizational unit in the appropriate object's property sheet in the Active Directory Users and Computers snap-in, or for a site in the site's property sheet in the Active Directory Sites and Services snap-in.

It is very important to monitor the Audit policy in order to prevent a rogue administrator from turning auditing off, performing a forbidden action, and turning auditing back on.

If you enable auditing of Policy Change successes and failures, you will enable the following events (most of these events are available only on Windows 2000):

608  

User Right Assigned  

609  

User Right Removed  

610  

New Trusted Domain  

611  

Removing Trusted Domain  

612  

Audit Policy Change  

Windows 2000 Only: 

613  

IPSec policy agent started  

614  

IPSec policy agent disabled  

615  

IPSEC Policy Changed  

616  

IPSec policy agent encountered a potentially serious failure.  

617  

Kerberos Policy Changed  

618  

Encrypted Data Recovery Policy Changed  

619  

Quality of Service Policy Changed  

620  

Trusted Domain Information Modified

As in most security events, much of the unique and interesting information about the event (such as which policies were modified, and by whom) is stored in the description field of the event.

Note: It is not possible in Windows NT and Windows 2000 to control administrator's actions. You can monitor almost anything an administrator does. However, because an administrator has the right to replace system components, as well as manipulate the security policy and logs on the system, a determined administrator could bypass auditing or at least erase his or her tracks. Only grant administrator access to trusted individuals.

Recommendation Always audit success and failure events of the Policy Change category.

For more information about Audit policy, see: "Policy_Audit_Event_Type," https://msdn2.microsoft.com/en-us/library/ms721903.aspx

"Auditing Security Events" (Audit policy settings for 4.0), https://technet2.microsoft.com/WindowsServer/en/library/2e9f38b6-9e30-4de2-bd8d-e658ab9e1f6d1033.mspx

"How to Determine Audit Policies from the Registry," https://support.microsoft.com/default.aspx?scid=kb;en-us;246120&sd=tech

Monitoring Uptime and Reboots

When the Event Log service starts (and it is one of the first services to start when you start the computer), event 6005 is generated in the system log. When the Event Log service shuts down gracefully, such as when the administrator shuts down the system, event 6006 is logged. When the system restarts unexpectedly, event 6008 is logged. These events are logged automatically; no configuration is needed to turn them on, and they cannot be turned off except by disabling the Event Log service.

The easiest way to gather and correlate these events into a useful report of system availability is to use the Uptime.exe utility, available on the Microsoft website.

More information about Event Log service informational events can be found at https://support.microsoft.com/default.aspx?scid=kb;en-us;196452&sd=tech

More information about the Uptime.exe utility can be found at https://support.microsoft.com/default.aspx?scid=kb;en-us;232243&sd=tech

Monitoring Crashes

Windows NT 4.0 and Windows 2000 can be configured to write an event to the event log when a fatal kernel-mode exception (Stop error) occurs. By default, Windows 2000 Professional and Windows NT 4.0 Workstation will not generate an event; however, the server products are configured to do so.

The event generated is event ID 1001, with an event source of "Save Dump."

To enable or disable event generation for a Stop error, select or clear the Write an event to the system log check box in the recovery settings section of the system control panel or in the registry. See the following article in the Microsoft Knowledge Base for more information: https://support.microsoft.com/default.aspx?scid=kb;en-us;235496&sd=tech

Monitoring Hardware Failures

The driver for a hardware component usually logs failures automatically. Listing all such events is beyond the scope of this document, but these classes of events generally have two characteristics in common:

  • The event source for such an event is the name of the driver.

  • The event category for such an event is either "warning," in the case of minor or recoverable failures, or "error," in the case of severe or unrecoverable failures.

These kinds of events should not be ignored, even if they occur repeatedly without any other symptom. You can investigate these events by consulting the support Web site of the vendor of the hardware.

Although a few vendors provide a way to do so, there is generally no way to configure logging of these kinds of events.

Recommendation You should always report hardware warning and error events to your centralized event-collection system and investigate each.

Monitoring Processes

Windows NT and Windows 2000 include the ability to log the creation and destruction of each process on the system. To enable this feature, set the system's Audit policy to audit success and failure events in the "Detailed Tracking" category.

When a process is created, it is given a process ID (PID), which is a number that is unique to that process for the entire time the process is active. The PID is referenced in a number of other security-related events, and is often useful in determining what a user was doing when other events were generated.

As with many other security events, logging detailed tracking events tends to generate a large number of events, particularly on user workstations and on servers that start large numbers of processes, such as Web servers that use Common Gateway Interface (CGI) extensively.

Enabling auditing of detailed tracking successes and failures will enable the following events:

592  

A new process has been created  

593  

A process has exited  

594  

A handle to an object has been duplicated  

595  

Indirect access to an object has been obtained

The description field of each of these events contains useful information such as the PID.

The downside of monitoring this category of events is that the events are rarely useful by themselves, and that there are a large number of them, so you need a fairly sophisticated analysis tool to associate another event, such as an object access event, with a detailed tracking event. The advantage is that you then will have more insight into what the user was doing.

For more information about process tracking, see "Process IDs and Handle IDs of Audit Events" at https://msdn.microsoft.com/library/winresource/dnwinnt/S8329.htm

Monitoring Applications

Applications usually log significant events to the application event log, although some applications log to their own application-specific log files. Although a detailed discussion of application monitoring is beyond the scope of this section, the same general guidelines apply: always investigate error events, and when determining log settings, set the application to log the minimum amount of information necessary to meet your requirements.

Object Monitoring

Introduction

Windows NT and Windows 2000 enable you to monitor accesses to specific objects: files and directories, registry keys, directory service objects, and kernel objects.

Auditing is done on a per-object and per-access basis: You specify which objects to audit and which accesses of those objects to audit. The auditable accesses vary among different object types and correspond with the permissions that can be assigned to that class of object.

As with other classes of event monitoring, it is very important to take a targeted approach to auditing object accesses. In your auditing plan, decide on the minimum number and type of objects that you must audit and then determine the minimum number of accesses that you must monitor for each type of audited object. An overly broad approach to auditing will have a significant impact on your system's performance and will result in the collection of much more data than is necessary or useful.

Auditing takes place when a handle to the object is obtained or released. The audits that this generates depend on the accesses that were requested (actually granted), not on actions actually taken. For example, it is not uncommon to see a "write" audit on a file object when the file was not actually modified. Microsoft is investigating this behavior; future versions of Windows 2000 may change this behavior.

If you enable success-and-failure auditing of the "File and Object Access" category of Audit policy, you will enable the following events (however, you will still have to set the appropriate auditing on each file or object to be monitored):

560  

Object Open  

561  

Handle Allocated  

562  

Handle Closed  

563  

Object Open for Delete  

564  

Object Deleted  

Windows 2000 Only:  

565  

Object Open  

566  

Object Operation

Monitorable Objects

Several kinds of objects can be audited. Each type of object has unique access types; that is, each kind of object is accessed in a way appropriate only to that kind of object. For example, while the "start" and "stop" accesses are appropriate to services, they don't make much sense when talking about files and directories.

There are also several standard access types, which apply to all objects. These standard rights deal with setting the security on the object. The standard rights are WRITE_DAC (modify permissions), WRITE_OWNER (change owner), READ_CONTROL (read security information), and DELETE (delete the object). More information about standard rights can be found at https://msdn2.microsoft.com/en-us/library/aa379607.aspx

When securing or requesting access to an object, an access mask is used. The access mask is a bit mask value, with each bit in the mask representing a specific access to the object. This allows the data structures involved to be very compact and quickly manipulated.

Here are the most common auditable objects:

More information about access masks is available at:

Object Auditing Architecture

You might wonder why this paper discusses access rights in such detail. The reason is that when you secure an object by setting its permissions or auditing, you must specify which accesses to allow, deny, or audit. This section will discuss the inner workings of object security, focusing on auditing.

Security Descriptors

All securable objects in Windows NT and Windows 2000 have an associated data structure called a security descriptor. The security descriptor contains four major pieces of information about the object:

  • The object's owner

  • The object's group, which is used for POSIX-style security

  • The object's discretionary access control list (DACL), which contains the list of users and groups that have permission to view or manipulate the object or who are denied access to the object

  • The object's system access control list (SACL), which contains a list of users and groups whose actions on this object are to be audited

The SACL is the most interesting of these in terms of auditing.

A SACL is simply a list of access control entries (ACEs). Each ACE contains three pieces of information:

  • The user or group to be audited

  • The specific access types to be audited, called an access mask

  • A flag to indicate whether to audit failed accesses or successful accesses

As an example, a file object might have a SACL similar to the following:

Everyone

Success

WRITE_DAC

Everyone

Failure

(All)

This SACL is very simple. It states that if anyone who is a member of the "Everyone" group changes the permissions on the file, an event is to be generated. The second entry states that if anyone attempts to access the file in any way and fails to do so due to insufficient permissions, an event will be generated.

More information about DACLs and SACLs is available at https://msdn2.microsoft.com/en-us/library/ms229936.aspx

Handles

Audits in Windows NT and Windows 2000 are generated when a handle to an object is opened.

Windows NT and Windows 2000 have a kernel-mode security subsystem. This means that a program attempting to access an object can access it only through the kernel; it cannot bypass the security system. Because the kernel memory space is isolated from user mode programs, a program refers to an object through a data structure called a handle. A typical access attempt goes like this:

  1. A user instructs a program to access an object (for example, File/Open).

  2. The program requests a handle from the system, specifying what kind of access (read, write, and so on) is desired.

  3. The security subsystem compares the DACL on the requested object to the user's token, looking for entries in the DACL that match either the user or a group the user belongs to and that have the accesses that the program requested.

  4. The system compares the SACL on the requested object to the user's token, looking for entries in the SACL that match either the effective rights being returned to the program or the rights requested by the program. If a matching failure audit ACE matches an access that was requested but not granted, a failure audit event is generated. If a matching success audit ACE matches an access that was granted, a success audit event is generated.

  5. If any accesses were granted, the system returns a handle to the program, which can then use the handle to access the object.

Of extreme importance here is the fact that when auditing occurs and the event is generated, nothing has happened to the object yet. This is critical to interpreting audit events. Write audits are generated before a file is written to, and read audits are generated before a file is read.

Why is this important? Because it is a common programming practice to request all accesses to an object, regardless of what the program intends to do. There is nothing to prevent a programmer from obtaining a handle with all accesses (which will trigger an audit event if any accesses were audited), performing a minimal access, and closing the handle. For example, say that your auditing strategy is to make sure no one changes permissions on a file (the WRITE_DAC access).

  1. The administrator sets a SACL on the file: Everyone::Success::Write_DAC

  2. A program opens the file with all accesses, causing a WRITE_DAC audit event.

  3. The program reads the file without modifying anything.

  4. The program closes the file.

Notice that now, as a security administrator, you are faced with an audit log that seems to indicate that the user changed permissions on the file, when the user actually did not.

What is the solution? None for right now. The important thing to remember is that auditing is based on handle manipulation, not on object manipulation. The audit event is true; you only have to understand what it is saying. This is yet another reason for using minimal, targeted auditing. As a side note, if you write programs that access objects, a good programming practice is to request only accesses you intend to use.

Inheritance

Permissions and auditing settings can be inherited from a parent container. For more information on inheritance of security settings, go to https://support.microsoft.com/default.aspx?scid=kb;en-us;220167&sd=tech

Changing Audit Settings on an Object

The SACL is manipulated through the advanced properties dialog of the security dialog for the object. To access the security dialog, right-click on the object, open the object's property sheet, and choose the Security tab.

Auditing on files and directories, registry keys, and services also can be set through Group Policy. To do so, open the Group Policy property sheet for the container where you want to set the policy, using the Active Directory Users and Computers snap-in. When you edit the policy, navigate to Computer Configuration, Windows Settings, Security Settings. You will see sections for the File System, Registry, and System Services, where you can specify permissions and auditing for these objects.

Monitoring User Activity

Monitoring Logons

You can monitor logon activity in Windows NT and Windows 2000 in a very detailed way by enabling success and failure auditing of the "Logon" category activity in the system's Audit policy. This can generate the following events, depending on whether you are auditing successes or failures or both:

528  

Successful Logon  

529  

Logon Failure: Reason: Unknown user name or bad password  

530  

Logon Failure: Reason: Account logon time restriction violation  

531  

Logon Failure: Reason: Account currently disabled  

532  

Logon Failure: Reason: The specified user account has expired  

533  

Logon Failure: Reason: User not allowed to logon at this computer  

534  

Logon Failure: Reason: The user has not been granted the requested   
logon type at this machine  

535  

Logon Failure: Reason: The specified account's password has expired  

536  

Logon Failure: Reason: The NetLogon component is not active  

537  

Logon Failure: Reason: An unexpected error occurred during logon  

538  

User Logoff:  

539  

Logon Failure: Reason: Account locked out  

540  

Successful Network Logon  

Windows 2000 Only:  

541  

IPSec security association established.  

542  

IPSec security association ended.  

Mode:  

Data Protection (Quick mode)  

543  

IPSec security association ended.  

Mode:  

Key Exchange (Main mode)  

544  

IPSec security association establishment failed because peer  
could not authenticate.  

545  

IPSec peer authentication failed.  

546  

IPSec security association establishment failed because peer  
sent invalid proposal.  

547  

IPSec security association negotiation failed.

In each of these events, description text gives detailed information about each specific logon.

Additionally, on Windows 2000, you can enable success and failure auditing of the "Account Logon" category of events, which enables the following events:

672  

Authentication Ticket Granted  

673  

Service Ticket Granted  

674  

Ticket Granted Renewed  

675  

Pre-authentication failed  

676  

Authentication Ticket Request Failed  

677  

Service Ticket Request Failed  

678  

Account Mapped for Logon  

679  

Account could not be mapped for logon  

680  

Account Used for Logon  

681  

The logon to account: <client name> by: <source> from workstation: <workstation>  
failed. The error code was: <error>  

682  

Session reconnected to winstation  

683  

Session disconnected from winstation

One of the most useful reasons to monitor logons is to capture account lockout events. Any reasonably secure site will have an account lockout policy, and every account lockout event will be usefuleither to the help desk for gathering statistics on how often users lock themselves out, or to your security team for watching for possible password-guessing attacks. Account lockout events are stored both on the local computer and on the authenticating domain controller. For that reason, it is often necessary to correlate the event logs from multiple domain controllers to determine which accounts are locked out. For more information, see "Account Lockout Event Also Stored in Security Event Log on Domain Controller" at https://support.microsoft.com/default.aspx?scid=kb;en-us;182918&sd=tech

For more information on auditing of user logons, see "Auditing User Authentication" at https://support.microsoft.com/default.aspx?scid=kb;en-us;174073&sd=tech

To read about a specific case where a logon is apparently not audited, see "Event Viewer Does Not Show IUSR_machinename Account Logon" at https://support.microsoft.com/default.aspx?scid=kb;en-us;188903&sd=tech

Monitoring the Use of User Rights

Windows NT and Windows 2000 include the ability to audit the use of user rights (also known as privileges). This setting can be either enabled or disabled, but you cannot choose which rights to auditit is all or nothing. Auditing the use of user rights will generate a very large number of audits, and in most cases the information these events provide will not outweigh the management considerations.

Enabling success and failure auditing for the "Use of User Rights" category will enable the following events:

576  

Special privileges assigned to new logon  

577  

Privileged Service Called  

578  

Privileged object operation

Recommendation Do not audit the use of user rights unless it is strictly necessary for your environment. If you must audit the use of user rights, it is advisable to purchase or write an event-analysis tool that can filter only on the user rights of interest to you.

Not all user rights are audited even if the "Use Of User Rights" category is enabled in the system's Audit policy. However, auditing of these events would cause the event logs to rapidly fill with events of little or no value.

The following user rights are never audited:

  • Bypass Traverse Checking (SeChangeNotifyPrivilege)

  • Generate Security Audits (SeAuditPrivilege)

  • Create A Token Object (SeCreateTokenPrivilege)

  • Debug Programs (SeDebugPrivilege)

  • Replace A Process Level Token (SeAssignPrimaryTokenPrivilege)

The following user rights are audited only if a specific registry setting is present:

  • Backup Files and Directories (SeBackupPrivilege)

  • Restore Files and Directories (SeRestorePrivilege)

The registry value to enable auditing of the backup and restore privileges is HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FullPrivilegeAuditing (REG_DWORD). Set the value to 1 to enable auditing. This setting can also be set through the security policy user interface in Windows 2000.

For more information on user rights auditing, see "Auditing User Right Assignment Changes" at https://support.microsoft.com/default.aspx?scid=kb;en-us;163905&sd=tech

Monitoring the Administrative Authority

Monitoring Account Management

The "Account Management" Audit policy is very detailed in Windows 2000 and in later service packs of Windows NT 4.0. By enabling success and failure auditing for this event category, you enable the following events:

624  

User Account Created  

625  

User Account Type Change  

626  

User Account Enabled  

627  

Change Password Attempt  

628  

User Account password set  

629  

User Account Disabled  

630  

User Account Deleted  

631  

Security Enabled Global Group Created  

632  

Security Enabled Global Group Member Added  

633  

Security Enabled Global Group Member Removed  

634  

Security Enabled Global Group Deleted  

635  

Security Enabled Local Group Created  

636  

Security Enabled Local Group Member Added  

637  

Security Enabled Local Group Member Removed  

638  

Security Enabled Local Group Deleted  

639  

Security Enabled Local Group Changed  

640  

General Account Database Change  

641  

Security Enabled Global Group Changed  

642  

User Account Changed  

643  

Domain Policy Changed  

644  

User Account Locked Out  

645  

Computer Account Created  

646  

Computer Account Changed  

647  

Computer Account Deleted  

648  

Security Disabled Local Group Created  

649  

Security Disabled Local Group Changed  

650  

Security Disabled Local Group Member Added  

651  

Security Disabled Local Group Member Removed  

652  

Security Disabled Local Group Deleted  

653  

Security Disabled Global Group Created  

654  

Security Disabled Global Group Changed  

655  

Security Disabled Global Group Member Added  

656  

Security Disabled Global Group Member Removed  

657  

Security Disabled Global Group Deleted  

658  

Security Enabled Universal Group Created  

659  

Security Enabled Universal Group Changed  

660  

Security Enabled Universal Group Member Added  

661  

Security Enabled Universal Group Member Removed  

662  

Security Enabled Universal Group Deleted  

663  

Security Disabled Universal Group Created  

664  

Security Disabled Universal Group Changed  

665  

Security Disabled Universal Group Member Added  

666  

Security Disabled Universal Group Member Removed  

667  

Security Disabled Universal Group Deleted  

668  

Group Type Changed  

669  

Add SID History (Success)  

670  

Add SID History (Failure)

There was a problem in Windows NT 4.0 prior to Service Pack 4 where only event 642 was logged. This was fixed in Service Pack 4; however, most of these events are still only logged in Windows 2000. For more information, see "Security Events Are Not Logged During Audit" at https://support.microsoft.com/default.aspx?scid=kb;en-us;173059&sd=tech

If File and Object Access auditing is enabled, you may see events for Security Accounts Manager (SAM) object access due to the default auditing set on SAM objects when they are created. For more information, see "Event 560, 562 When No Objects Have Been Selected for Auditing" at https://support.microsoft.com/default.aspx?scid=kb;en-us;149401&sd=tech

Monitoring Directory Services Access

To enable auditing of directory services accesses, select the appropriate success/failure boxes in the Audit Policy settings. Directory service auditing settings are then set in the security properties dialog of each individual directory service object.

To date, there is no published list of directory service events. This location will be updated when such a list becomes available.

For more information on how to configure directory service auditing, see "How to Enable Auditing of Directory Service Access" at https://support.microsoft.com/default.aspx?scid=kb;en-us;232714&sd=tech

Low-level Monitoring of the SAM

Since the SAM in Windows NT and Windows 2000 is stored in the registry, it is possible to monitor changes to the SAM by auditing the registry keys that contain the SAM information.

Although this is possible, auditing the entire SAM will generate a staggering number of events and will cause a significant if not debilitating load on a system.

If you must monitor the SAM by auditing the registry, consider doing so in a targeted manner, auditing only the registry keys for the SAM objects in which you are interested.

For more information, go to https://support.microsoft.com/default.aspx?scid=kb;en-us;186374&sd=tech

For an example of "targeted" auditing of the SAM, see "How to Identify the User Who Changed the Administrator Password" at https://support.microsoft.com/default.aspx?scid=kb;en-us;173939&sd=tech

Performance Monitoring

Introduction

Whole volumes have been written on the subject of monitoring the performance of Windows NT. This document will touch only on the highlights.

Understanding how to monitor the performance of your computers gives you several advantages:

  • Capacity planning. Deciding how much hardware you need to buy for current and future needs.

  • Identifying bottlenecks. When a server becomes unable to provide a service, it is often because it has run out of some resource.

  • Identifying the target of a denial-of-service attack. These attacks typically cause a shortage in some system resource, which is identified in the same way as any other performance bottleneck.

Baselining

Many performance problems cannot be identified by just looking at one performance monitor log, taken when a problem occurs, because many performance values vary widely from installation to installation. For this reason it is highly recommended that you regularly baseline your servers.

Here are some baselining tips:

  • Baseline at a long interval (15 minutes or more) for a long period (one to two weeks). This will allow you to go back and see usage patterns vary based on time of day and day of week.

  • Include all counters in your baseline. You never know what you are going to want to compare.

  • Regularly baseline, and rebaseline if a configuration change is made. Usage patterns vary hour to hour and day to day on a cyclical basis, but usage patterns also change over time, and small configuration changes can have large performance impacts.

Critical Counters

The four major bottlenecks on a system are:

  • CPU load

  • Available memory

  • Disk system performance

  • Network bandwidth

When you are first trying to zero in on a performance issue, you might want to take a look at the following counters for a quick overview of how the computer is doing:

  • Memory\Available Bytes. If this counter stays low (below 4 megabytes), you might have a memory bottleneck.

  • Memory\Pages/sec. If this counter averages over 10 on a given interval, you might have a memory bottleneck.

  • Memory\% Committed Bytes In Use. If this counter is constantly near 100 percent, you might have a memory bottleneck.

  • Processor\% Processor Time. If this counter is constantly near 100 percent, you might have a CPU bottleneck.

  • Physical Disk\% Disk Time. If this counter is constantly over 67 percent, you might have a disk bottleneck.

  • Physical Disk\Avg. Disk Queue Length. If this counter averages over 2, you might have a disk bottleneck.

  • Network Segment\% Network Utilization. If this counter approaches the typical limit for your kind of network, you might have a network bottleneck (Ethernet = 35%, switched Ethernet = 85%, token ring = 75%).

Many causes other than security-related ones would create a bottleneck in one of these areas. However, these counters are a very good starting point for determining the general health of a system, and should probably be included in any performance-monitoring plan.

Other Interesting Counters

When monitoring performance for security reasons, you will typically monitor reactively. Some situation will occur such as a denial-of-service attack, and you will be monitoring to find out which resources are being starved or which process is starving the system of resources.

Some counters, however, might be useful if monitored proactively:

  • NTDS/Kerberos authentications and NTDS/NTLM authentications. If your rate of authentication requests rises suddenly (and it is not a Monday morning), then someone could be trying a password-guessing attack against your network. Check your event logs for a large number of authentication failures.

  • NTDS/SAM Enumerations/sec. If this counter rises suddenly, someone may be scanning your SAM in preparation for a password attack.

  • NTDS/KDC AS Requests. A sudden rise in this counter could indicate an attempt to break in to your network.

  • DNS/Total Query Received/sec. A sudden rise in this counter (on a DNS server only) could mean that someone is attempting to scan your DNS server for hosts to attack.

  • DNS/Zone Transfer Request Received. A sudden rise in this counter (on a DNS server only) could mean that someone is trying to get a list of hosts on your network in preparation for an attack.

NTDS counters are available only on Windows 2000 domain controllers.

There are other counters for different services, such as Microsoft Internet Information Server and Microsoft Exchange Server, which could also yield information proactively about security threats. Be creative when selecting counters. Try downloading hacker tools and trying them against a test system, and watching for changes in likely performance counters.

Above all, make sure to have baseline performance logs. A sudden spike may mean something, but it may not. You may find that a spike happens at the same time every day or every week and that there is nothing to worry about.

Performance Logs and Alerts in Windows 2000

Windows 2000 replaced the Performance Monitor application with two new Microsoft Management Console (MMC) plug-ins: System Monitor, which displays charts of performance counters based on real-time or log data, and Performance Logs and Alerts, which is used to generate performance logs and is also used to generate alerts when certain configurable conditions occur.

The logs generated by Performance Logs and Alerts are more versatile than the Windows NT 4.0-style logs. The logs can be circular or sequential, and can be stored in SysMon-readable binary format or in text format, suitable for importing into a database or spreadsheet.

The alert function is especially interesting from a security standpoint. When a specified counter or counters cross a specified threshold, it causes a specified action. The action can be an event (source: SysMonLog, event ID: 2031), or it can start a performance log or run a specific command. If a command is specified, the alert function can pass information about the alert to the command.

More Information

For more information on Windows NT and Windows 2000 performance monitoring and tuning, see:

  • Microsoft Windows 2000 Resource Kit, Microsoft Press, 2000

  • Microsoft Windows NT Workstation 4.0 Resource Kit, Microsoft Press, 1996

  • Microsoft Windows NT 3.51 Resource Kit, Microsoft Press, 1994

Other Monitoring

Detailed Logging of Specific Components

Many components of Windows NT and Windows 2000 include their own logging facilities, separate from the Event Log. Here is a short list of components that support this type of logging:

Checked Builds

When writing new programs, it is often useful to add special instructions to create detailed logs of the activities of components of those programs. This aids in troubleshooting and speeds development. Microsoft does this often when working on a new component of Windows NT or Windows 2000. Microsoft calls this "checked" code.

Because such logging introduces significant performance impact, this code is usually disabled in the final version of the software.

However, Microsoft makes checked versions of Windows available to developers as part of the Microsoft Developer Network (MSDN) subscription, and Microsoft Product Support Services occasionally distributes checked code to customers to help troubleshoot a problem.

You should never run a production system with checked code when you are not troubleshooting a problem. Here is a short list of detailed logging that is available in Windows and is commonly used in troubleshooting. If you need more information or want to obtain the checked code, contact Microsoft Product Support Services.

Checked NetLogon

"Using the Checked Netlogon.dll to Track Account Lockouts" at https://support.microsoft.com/default.aspx?scid=kb;en-us;189541&sd=tech

Checked UserEnv

"Debugging User Profiles and System Policies in Windows NT 4.0" at https://support.microsoft.com/default.aspx?scid=kb;en-us;154120&sd=tech

Monitoring Utilities

Event Log Management

Microsoft provides a number of tools that can aid in event log management and analysis:

  • Systems Management Server (SMS) 2.0. Converts certain events to SNMP traps and reports them to an SNMP management console and/or an SMS trap listener, which logs them in a central database.

  • Dumpel.exe. A utility in the Windows NT 4.0 and Windows 2000 resource kits that can dump events from a local or remote event log into a comma-delimited text file, suitable for import into another application for analysis.

  • Uptime.exe. A utility on the Microsoft Web site that analyzes event logs on a system and provides a report on that system's availability.

  • Elogdmp.exe. A utility in the Windows 2000 Resource Kit that dumps an entire event log to a comma-delimited text file.

  • Cybersafe Log Analyst. A utility in the Windows 2000 Resource Kit that assists in analyzing the Windows 2000 security event log.

  • Seagate Software Crystal Reports. A utility in the Windows NT 4.0 and Windows 2000 resource kits that generates custom reports based on information in the Windows 2000 event logs.

Auditing and Audit Policy

Auditpol.exe. A utility from the Windows 2000 Resource Kit that allows an administrator to view or modify the local Audit policy from the command line.

Performance Monitoring

  • System Monitor. An MMC plug-in, included with Windows 2000, that monitors performance in real time or collects or examines performance logs.

  • PerfMon4.exe. The Windows NT 4.0 version of PerfMon, included with Windows NT 4.0 and with the Windows 2000 Resource Kit.

  • Setedit.exe. PerfMon Chart Settings Editor, a Windows 2000 Resource Kit tool that allows the creation of chart settings files so that standard sets of performance counters can be quickly examined.

  • Perfmtr.exe. A Windows 2000 Resource Kit command-line performance monitoring tool.

  • Exctrlst.exe. A Windows 2000 Resource Kit utility that displays information about currently installed extensible performance counters.

  • Diskperf.exe. A Windows NT 4.0 and Windows 2000 utility that enables/disables the disk performance counters.

Microsoft TechNet security Web site: https://www.microsoft.com/technet/security/default.mspx

"Securing Microsoft Windows NT Installation," https://msdn2.microsoft.com/en-us/library/ms995342

Security event descriptions: https://support.microsoft.com/default.aspx?scid=kb;en-us;174074&sd=tech