Account Management and Directory Service Access
The Account Management category allows you to track changes to users, groups, and computers and is invaluable for monitoring a number of activities. The best way to manage access is to grant it to groups, not directly to users. The Account Management category allows you to easily identify when a group's membership changes. An attacker who gains administrator access to a system often starts by creating a new user account for use in future attacks. Account Management makes tracking new-user-account creation easy. One other way Account Management helps is that it makes administrators accountable for their actions. If someone accidentally deletes a user account or misapplies some kind of change to a user or group, Account Management provides an audit trail.
The Directory Service Access category provides low-level auditing on AD objects and their properties. Because this category is related to AD, enabling auditing for it on non-DC computers has no effect. The Directory Service Access category overlaps to a degree with Account Management because users, groups, and computers are AD objects. However, Account Management reports high-level changes to users, groups, and computers, and Directory Service Access provides very low-level auditing on AD objects, including users, groups, and computers. Account Management has a unique event ID for each type of object and each access that can be performed against the object. Directory Service Access, on the other hand, reports just one event, event ID 566, for all types of activity. Event ID 566 lists the object type, the object name, the user who accessed the object and the type of access the user had to the object. In the event that Figure 3 shows, the administrator has changed the job title in Susan's account.
Although Directory Service Access is a powerful category, it can be a bit overwhelming to use. On Win2K DCs, the Directory Service Access audit policy's default setting logs all successful and failed attempts to modify AD objects, a setting which results in a lot of events. Additionally, the object type and property names in event ID 566 come directly from AD's schema and can be rather cryptic. For instance, a user's city field is the l field (for locality) and the last name is sn (for surname). Account Management is usually a more practical category to use for auditing maintenance of users, groups, and computers, but Directory Service Access provides the only way to audit changes made to other important AD objects such as GPOs and organizational units (OUs).
New in Windows 2003: Windows 2003 fixes a bug in Win2K that pertains to user password changes and resets. Although the Win2K documentation says that Win2K logs event ID 628 for password resets, Win2K actually logs event ID 627 for both password changes and resets and always reports these events as a password change. Windows 2003 logs event ID 627 for password changes and event ID 628 for password resets.
Auditing File Access
The Object Access category gives you the ability to monitor access to files, folders, printers, registry keys, and system services, but most people use this category to monitor files and folders. If you enable this category, your Security log will immediately start showing some events logged in connection with objects accessed in the SAM. However, you won't see any access events for files or other objects because every object has its own audit settings and auditing is disabled on most objects by default. This is a good thing, because if you tried to audit every access attempt on every file and other object, your system would grind to a halt and your Security log would quickly fill—no matter how much space you allocated to it. I recommend using this category only for important files on which audit trails are critical.
To enable auditing for a given object, open the object's Properties dialog box, select the Security tab, click Advanced, select the Auditing tab, and click Add. For instance, in Figure 4, you see the audit settings for 1st Quarter Cost Centers.xls, which I opened from Windows Explorer. Notice that you can specify users or groups whose access to this file you wish to audit, as well as exactly which types of access you want to audit and whether to record successful and/or failed access attempts. After you enable auditing on an object, Windows begins recording open and close and other events according to the audit policy for that object.
New in Windows 2003: The Win2K Security log does a good job of telling you which types of access a user and his or her application has to an object but not which types of access the user actually exercised. For instance, Bob might open a document to which he has read and write access. At that point, Win2K logs event ID 560, which shows that a user with List Folder / Read Data and Create Files / Write Data access types opened a file. When Bob closes the file, Win2K logs event ID 562, which shows a user closed a file. But in Win2K, there's no event to indicate whether Bob actually changed the file. Windows 2003 introduces event ID 567. If Bob changed the file on a Windows 2003 machine, you would see an event ID 567 between the open and close events. Event ID 567 tells you the name of the object, the user, and what type of access the user actually exercised. If you don't see an event ID 567, then you know the user didn't update the file.
Register
