Monitoring Privileges and Administrators in the NT Security Log

You can't control what administrators do, but you can monitor their actions

In, "Interpreting the NT Security Log," April 2000, I showed you how to use three related audit categories—logon and logoff, file and object access, and process tracking—to monitor user activity. (See "Other Articles in This Series," page 104, for a quick reference to previously published articles in this series about the Windows NT Security Log.) This month, I show you the privilege use and account management categories. You'll find the latter especially useful for monitoring the activity of users who perform all-powerful administrator activities. Be aware that NT's terminology for audit categories is inconsistent. The NT Event Viewer uses slightly different names for audit categories than User Manager does. Table 1, page 104, helps resolve the confusion.

Privilege Use
The privilege use category lets you track rights as users exercise them. (NT uses the terms privilege and right inconsistently.) You manage user rights assignments from the Start menu's Programs, Administrative Tools, User Manager, Policies, User Rights Policy dialog box, which Screen 1, page 104, shows.

When a user successfully invokes a right, such as Change the system time, NT logs event ID 577, which Figure 1, page 105, shows. The Privileges field identifies which rights the user used (SeSystemtimePrivilege, in this case). You might notice that the Privileges field's descriptions are somewhat different from the descriptions that User Manager displays in the User Rights Policy dialog box, but the two descriptions are usually easy to resolve. The Primary User Name and Client User Name fields identify the user who invoked the right. The client information comes into play only when a user performs actions from a remote system over the network. When a user changes the local system time, only the primary user information is relevant. However, when a user connects to an NT system and changes the system time over the network, the primary user information identifies the server application's (in this case the Server service's) user account, and the client user information reflects the user who accessed the system. The event information includes the user's Primary Logon ID, which lets you determine in which logon session the event occurred. For more details, see the discussion of the logon and logoff category in "Interpreting the NT Security Log."

Some privileges pertain only to objects. For example, one privileged object operation is SeSecurityPrivilege, which is required whenever you open the security log from the Event Viewer. Event ID 578 identifies when users invoke object privileges and specifies which privileges the user used.

Whenever a user uses a privileged action or object, event ID 577 or 578 notifies you that a user attempted to invoke a right. Both events succeed or fail depending on whether the user possessed the right he or she tried to invoke.

Users invoke some rights so frequently that if NT logged them each time, the event log would overflow with useless information. Two rights in this category that have meaning to users and administrators are SeBackupPrivilege and SeRestorePrivilege, which users invoke whenever they back up or restore an object. To audit these rights, NT simply records users' rights whenever users log on. After event ID 528 (successful logon), you'll often see event ID 576, Special Privileges Assigned to New Logon, which Figure 2 shows. This event identifies the user's name and domain and the user's logon ID, which lets you link this event to the corresponding logon session. Event ID 576 lists the rights assigned to the user in the Assigned field. Other rights that appear under event ID 576 are SeAuditPrivilege, SeCreateTokenPrivilege, SeAssignPrimaryTokenPrivilege, and SeDebugPrivilege.

Account Management
The account management category lets you track the activities of administrators and account operators as they maintain users and groups. Unfortunately, this category usually doesn't tell you exactly which user or group properties the administrator or account operator updated but simply records which account the administrator updated, which administrator updated the account, and whether that administrator created, modified, or deleted the account. In a few cases, which I'll discuss, NT provides more specific information. Keep in mind that NT records these events on the system where the account resides. If you create a new user account on a member server's local SAM, NT records the associated events in that server's log. If you change a domain user account, NT records the event in the PDC's log.

When you create a new user account, the security log records event ID 624, which Figure 3 shows. This event identifies the account operator or administrator by Caller User Name and Caller Domain. In addition, the event specifies the Caller Logon ID, which lets you link the event with the corresponding logon session. NT uses the New Account Name, New Domain, and New Account ID fields to identify the new account. (Account management events use the term Account ID to refer to an account's SID.)

When you delete a user, NT logs event ID 630, which uses the same information as event ID 624 does to identify the user who deleted the account. Event ID 630 identifies the deleted account by Target User Name, Target Domain, and Target Account ID. If a user changes a user account, NT logs event ID 642. This event doesn't specify which properties (e.g., description, logon hours) the user changed; the event identifies only the user who performed the change and which account the user updated.

NT logs specific events for a few actions performed on user accounts. Event IDs 626 and 629 tell you that someone enabled or disabled a user account, respectively. When users attempt to change their password, NT logs event ID 627 and indicates success or failure depending on whether the user had authority to change the password and whether the password complied with the domain password policy. When an administrator changes a user's password, NT logs event ID 628.

The account management audit category also tracks group maintenance. NT logs all operations you can perform on groups and uses specific event IDs depending on whether the group is local or global. Creating a global group produces event ID 631, and deleting a global group logs event ID 634. If you change a global group property other than the group's list of members, NT logs event 641. The account management category of events provides more granular information about group membership changes, logging separate events when you add a global group member (event ID 632) or remove a global group member (event ID 633). Unfortunately, these events use only the SID to identify the member user or group. The account management category logs the same events for local groups: event ID 635 for group creation, event ID 638 for group deletion, event ID 639 for a group change, event ID 636 for member addition, and event ID 637 for member removal.

When an administrator uses User Manager to grant a right to a user, NT logs event ID 608, which Figure 4 shows. This event shows the right the administrator granted as well as the user to whom the administrator assigned the right. In the Assigned By section, User Name, Domain, and Logon ID identify the administrator who assigned the right. The Logon ID lets you link the event to the corresponding logon session. When an administrator revokes a user right, NT logs event ID 609, which provides the same user right information as event ID 608 does and identifies the administrator who removed the right. Don't confuse event IDs 608 and 609 with events in the privilege use category. The privilege use category's event IDs 576, 577, and 578 tell you when users (not administrators or account operators) try to use rights.

The account management category includes two other events of interest. When NT locks out a domain user account after repeated unsuccessful logon attempts, the PDC records event ID 644. Whenever an administrator changes the domain's password requirements or lockout policy, NT logs event ID 643. Although this event doesn't identify which values changed, password and lockout policies are semipermanent settings, so just knowing that they've changed is important. NT also logs event ID 643 on servers and workstations when you change the local system policy.

The account management category is especially useful for tracking the activity of users who have administrator or account operator authority. Although you can't control what they do, at least you can monitor their actions. But what if they try to cover up their tracks by tampering with the security log? In the next article in this series, I'll discuss the remaining audit categories and show you how to use them to detect such actions.