The User Name, Domain, and Logon ID fields under Assigned By ostensibly identify who changed the rights assignment. But whereas NT administrators assign rights directly through User Manager, Win2K administrators grant or revoke rights indirectly through Group Policy Objects (GPOs). Because of this difference and because a user's local system reads Group Policy and makes the associated rights assignment changes, event ID 608 lists the user's local computer account as the Assigned By user. To get a clue to which administrator changed the rights assignments, you must enable the Audit directory service access category to audit changes to GPOs in Active Directory (AD—for information about how to audit such changes, see "Mining the Win2K Security Log," April 2001).
When you revoke a user right, Win2K logs event ID 609 (user right removed) the next time Win2K applies Group Policy. This event's User Right field is similar to the User Right field in event ID 608. The Removed From field specifies the users or groups who lost the right or rights. The User Name, Domain, and Logon ID fields under Removed By specify the local computer account, just as event ID 608's Assigned By fields do. Win2K logs both events on the computers on which Win2K applies the GPO that contains the rights assignments, but the OS logs changes to GPOs on the domain controller (DC) to which an administrator connected when he or she edited the GPO.
Audit policy change also lets you track changes to trusted relationships with other domains. When an administrator uses the MMC Active Directory Domains and Trusts snap-in to add a new trusted domain, Win2K logs two identical occurrences of event ID 610 (new trusted domain) on the DC to which the administrator connected. Event ID 610's Domain Name field identifies the newly trusted domain. To find out who added the trust relationship, look at the User Name, Domain, and Logon ID fields under Established By.
Win2K also logs one occurrence of event ID 620 (trusted domain information modified) on the DC. However, this event doesn't supply any additional information. When you remove a trusted domain, Win2K logs two occurrences of event ID 611 (removing trusted domain). This event includes the same fields as event ID 610, except that the User Name, Domain, and Logon ID fields fall under the heading Removed By rather than Established By.
Event ID 610, event ID 611, and event ID 620 expose another bug in Win2K auditing: Win2K logs these events when you add or remove a trusting relationship as well as when you add or remove a trusted relationship. The events tell you only that a trust relationship was added or removed—not whether the specified domain is trusted or trusting.
Win2K logs event ID 612 (audit policy change) whenever Group Policy application results in a change to a computer's audit policy. The event's New Policy field specifies which audit categories were enabled for success or failure. (For example, Figure 4 shows that I enabled auditing for successful and failed policy changes.) As in event ID 608, event ID 612's User Name, Domain Name, and Logon ID fields under Changed By don't specify which administrator changed the audit policy because Win2K doesn't detect changes until Group Policy is actually applied. Still, event ID 612 is useful for catching changes to audit policy.
You can also use the Audit policy change category to monitor several other policy changes. Event ID 617 signals a change to the Kerberos policy, which controls ticket lifetimes and renewal. (Win2K doesn't limit event ID 617 to explicit administrator changes to the Kerberos policy but logs the event each time a DC applies Group Policy.) When you change Group Policy's Encrypted Data Recovery Agents section, which controls who can decrypt files that are encrypted with the Encrypting File System (EFS), Win2K logs event ID 618 (encrypted data recovery policy changed). Again, the event's User Name, Domain Name, and Logon ID fields under Changed By don't truly tell you which administrator changed the policy; these fields simply specify the local computer account.
You can also monitor changes to a computer's IP Security (IPSec) policy, although some confusion exists about the events that give you this ability. Win2K documentation (at http://www.microsoft.com/technet/security/monito.asp) lists the IPSec audit events—event ID 615 and event ID 616—as part of the Audit policy change category, but Event Viewer categorizes these events under Detail Tracking (i.e., the Audit process tracking category). Moreover, Win2K logs these events even when you don't enable the Audit policy change or Audit process tracking category. At any rate, when you assign an IPSec policy through a GPO in AD or through a computer's local GPO, Win2K logs event ID 615. If you use a GPO in AD, event ID 615's description specifies IPSEC PolicyAgent Service: Using the Active Directory Storage policy. If you assign the IPSec policy through the local GPO, event ID 615's description specifies IPSEC Policy-Agent Service: Using the Active Local Registry policy, as (i) there's no Active Directory Storage policy or (ii) the Active Directory Storage policy couldn't be applied successfully and there's no Cached policy. If Win2K encounters a problem applying the policy, the OS logs event ID 616 (IPSec policy agent encountered a potentially serious failure).
Watching for changes to Group Policy is an important step in ensuring your network's integrity. But you also need to remain vigilant about monitoring physical access to network systems. Win2K can help you accomplish this goal as well.
Audit System Events
The Audit system events category provides several useful security events. Whenever a Win2K system boots, Win2K logs event ID 512 (Windows NT is starting up). You can use this event to catch unauthorized system reboots—a potentially significant situation because Win2K is vulnerable whenever someone who has physical access to the system shuts it down. (For details about avoiding this vulnerability and other potential security breaches, see "Protect Administrator Privileges," February 2000.)
Although Win2K documentation claims that Win2K logs event ID 513 (Windows NT is shutting down) whenever a system shuts down, the claim is inaccurate. To determine how long a system was down, compare the date and time of an event ID 512 occurrence with the last event that Win2K recorded before the occurrence.
Register
