As described earlier, you can track several categories of security events. This section provides examples for most of these categories. This set of examples does not constitute a strategy for using the auditing capabilities of Windows NT; it merely serves as an introduction to show how to turn on auditing and to help you interpret these events when you enable auditing for your Windows NT system.
In this example, a user opens, modifies, saves, and closes a text file. Each of these actions generates an audit event. You must be logged on as an administrator, and make sure to enable auditing for file and object access in User Manager.
1. Create a .txt file using Notepad (it need not contain any text).
2. In Windows NT Explorer or in My computer, right-click on the .txt file icon, select Properties, and then click the Security tab.
3. Click Permissions, click Add, and then click Show Users.
4. Click to select the user, click Add to add the selected user to the list, and then click OK.
5. Give the user Full Control, and then click OK.
6. Click Auditing, click Add, and then click Show Users.
7. Click to select the user, click Add to add the selected user to the list, and then click OK.
8. Select the Read Success, Read Failure, Write Success, and Write Failure check boxes.
9. Click OK in both dialog boxes.
10. Have the user double-click the .txt file, write data to the file, save it, and then close the file.
This results in audit events, as shown in the following illustration:
From this view of the security log, you get a quick summary of security-related events that occurred. Double-click the first event to examine the details. (For example, details of this first event are shown in the Event Detail box.)
The data that needs to be interpreted is listed in the Description list box. The following table summarizes the audited events for this example, in the order they occurred:
Table 6.1 Security Events for File Access Example
Event ID and description |
Analysis |
Event 560: Object Open | In this sequence of events, Windows NT is doing some internal checks, such as checking to see if the file exists and checking to see that there is no sharing violation. |
Event 592: A New Process Has Been Created | In this series of events, a new process is created for Notepad.exe. This process opens the .txt file for reading. Next, the process allocates, then closes, a handle to the file. Note that from the security log it is clear that Notepad does not keep an open handle to the file; it simply keeps a copy of the file in memory. |
Event 560: Object Open | The process opens the file for reading and writing, and since the event is a successful audit, new data is written to the file. Next, the handle is allocated for the open file, then closed. |
Event 593: A Process Has Exited | This event indicates that the process, whose process ID relates to Notepad.exe, has ended. |
In this example, auditing is enabled by using User Manager to enable auditing for Success and Failure of Use of User Rights.
Use of User Rights generates audit events when a process initiates an operation that requires special privilege. For example, in order to set the system time, a user first must be given the user right to "Change The System Time" in User Manager.
For more information about User Rights see "User Rights" in the "High-Level Security" section later in this chapter.
When the user tries to change the system time, only one event is generated, as shown in the following illustration:
This event indicates that a privileged service was called and that a server component named Kernel has called an audit check on the primary username of the user. The audit type is a Success Audit, meaning that the user successfully exercised the right to use the SeSystemtimePrivilege (that is, the right to change the system time).
In this example, a new user account is added to the user accounts database. Auditing is enabled in User Manager by specifying both Success and Failure of User and Group Management. This generates four audit events, as shown in the following illustration:
Table 6.2 Security Events for Added User Account
Event ID and description |
Analysis |
Event 632: Global Group Member Added | A new security ID (member) is created and added to the group represented by the target account ID. This is a default global group Domain Users. At this point, the security ID does not have a username allocated to it. |
Event 642: User Account Changed | This event indicates that the account name of the security ID represented by the Target Account ID has been changed to the new user's. |
Event 636: Local Group Member Added | This event indicates that the account represented by the new user's security ID is created. The new user is added to the local group represented by the security ID under Target Account ID (Users). |
In this example, auditing is enabled in User Manager for both Success and Failure of Restart, Shutdown and System.
In this example, seven events were generated. Note, however, that the number of events generated is related to the number of trusted systems that you start when the system is restarted. This number might vary if you replicate this scenario on your own Windows NT computer.
Table 6.3 Security Events for System Startup
Event ID and description |
Analysis | |||
Event 512: Windows NT | Identifies the date and time the system started. | |||
Event 514: Authentication | The description of this event says An authentication package has been loaded by This is the standard authentication package shipped with Windows NT. | |||
Events 515: Trusted | The description for each of these events says A trusted logon process has registered with the The logon process name is listed for each of these events, as follows: Winlogon Each of these events is a successful audit in the category of system event. These events indicate that the respective logon processes have registered with the Local Security Authority and are now trusted to submit logon requests. | |||