SACL Inheritance
In Win2K, SACLs follow the same inheritance scheme that DACLs follow. By default, SACL entries automatically flow from parent folders and registry keys to child objects. For example, when you enable auditing of failed writes on a folder, all the files and subfolders in that folder inherit its SACL. You can customize SACL inheritance at several levels.
At the child level. To block inherited parent SACL entries from reaching a child object, open the child object's Access Control Settings dialog box, go to the Auditing tab, and clear the Allow inheritable auditing entries from parent to propagate to this object check box. Then, click OK or Apply. If any inherited SACL entries are already in place when you clear this check box, Win2K asks whether you want to remove them or make noninherited copies of them.
At the parent level. To override child objects that have blocked inheritance, open the parent object's Access Control Settings dialog box, which Figure 8 shows, go to the Auditing tab, and select the Reset auditing on all child objects and enable propagation of inheritable auditing entries check box. After you click OK or Apply, Win2K resets auditing on all child objects and clears the check box so that you can selectively block inheritance on child objects. This reset option is useful when you aren't sure whether the system is overriding auditing on child objects and you want to start over from scratch.
You can also control how deep and to which child object inheritance flows for each SACL entry. To edit an individual SACL entry, open the parent object's Access Control Settings dialog box, go to the Auditing tab, select the entry, and click View/Edit to open the Auditing Entry dialog box, which Figure 9 shows. This dialog box shows two options for controlling how Win2K propagates the entry to child objects. The Apply onto drop-down list controls which types of objects receive the audit entry. The list defaults to This folder, subfolders and files, but you can select any combination of those three items. (Figure 9 shows a setting to audit failed reads that occur only on files, not on folders.) The Apply these auditing entries to objects and/or containers within this container only check box lets you control whether Win2K propagates the entry to objects that reside only in the immediate folder or whether Win2K recursively propagates the entry to all child levels from this point down.
Best Practices
What strategies should you use when you enable object auditing? First, use Group Policy if you have a certain directory or registry key that you want to audit on multiple systems. For example, if you want to audit failed writes on the \%system-root% directory of every computer in your domain, open the MMC Active Directory Users and Computers snap-in and right-click the domain root. Select Properties, and go to the Group Policy tab. Select the Default Domain Policy Group Policy Object (GPO), click Edit, then maneuver to Computer Configuration, Windows Settings, Security Settings, File System. Right-click File System, and select Add File. Type
%systemroot%
and click OK. A permissions dialog box similar to the one that Figure 1 shows will appear. Follow the steps I described earlier to enable auditing on an object. Carefully consider how widely you enable auditing. I don't recommend limiting whom you audit because attackers often use stolen or guessed passwords to impersonate other users. Therefore, specify the Everyone group in audit control lists to ensure coverage for all users. However, I do recommend that you carefully limit which objects and access types you audit. Object auditing generates large amounts of data. To reduce the amount of useless noise in your Security log, enable fewer access types for fewer objects.
To the inexperienced eye, Audit object access events can seem to indicate more activity than truly is happening on your system. You must remember that Win2K doesn't audit actual operations (e.g., read, write) on objects; rather, it audits an application's request to access the object. Therefore, event ID 560's Accesses field documents only the access that a user might have used, not whether the user actually took advantage of that access. The problem is exacerbated by applications that automatically request all access types to an object regardless of the access that the user needs. Microsoft has stated that it might eventually enhance Win2K auditing to audit actual operations rather than potential access.
Useful Functionality
You can use the Audit object access category to solve some challenging puzzles, such as whether anyone has tried to access data they shouldn't or who might have changed a certain file. Despite the inconvenience of excessive logged data, this category earns its place in your auditing arsenal.
End of Article
Prev. page
1
2
[3]
next page -->
