In addition to letting you audit system-wide events (such as users logging on), Windows NT gives you the ability to record such events as whether a specific user fails to open a given object (such as a file or printer) for a particular type of access.
Note
Only files and directories in NTFS partitions can be audited, and it is only access that is auditable, not intent. In other words, the audit log records will show that a particular user opened a specific file or directory; it will not tell you what the user's intent was. Copying a file, reading a file, or viewing a file's attributes all write the same set of audit records to the log.
To be able to audit object access in this way, you must first use the Audit Policy dialog of User Manager to enable auditing of file and object access events. You can enable auditing of success or failure events, or both. This establishes the global object-access auditing policy for the system. The global policy determines whether object-specific auditing will occur at all; to record access events for a particular object, you must also specify the type of auditing to be performed for that object. File Manager lets you set up auditing for files and directories, Print Manager lets you configure auditing for printers, and Registry Editor lets you specify auditing for Registry entries.
In a sense, object-access auditing works like a building's electrical system. You can turn on and off switches for lamps throughout the building, but if the master circuit breaker is off, no lamps will actually turn on. On the other hand, if the master circuit breaker is on, then only those lamps whose switches are in the on position will light up.
Because the security log is limited in size, and because a large number of routine audit records can make it difficult to find records that suggest a security problem, you should carefully consider how you will audit object access. Generating too many audit records might require you to review and clear the security log more often than is practical. On the other hand, judicious use of object-access auditing can be invaluable in helping you identify areas where your security policy should be tightened or even where a security breach has been attempted successfully or unsuccessfully.
For example, if you use permissions to control users' access to sensitive files and directories, you should enable auditing of those users' access to those files and directories to ensure that the permissions are working as expected.
If a directory has a list of users whose access to the directory is to be audited, a new file added to the directory will inherit the auditing list from the directory. You can ensure that Windows NT Workstation will record access to new files by making sure the new files are placed in directories with auditing lists.
Note
Only new files and directories inherit auditing lists from the directory in which they are created. To ensure that access to existing files will be audited, be sure to select both Replace Auditing On Subdirectories and Replace Auditing On Existing Files in the Directory Auditing dialog box when creating a directory auditing list.
For procedures for managing access auditing for files and directories, see the "File Manager" chapter in the Windows NT Workstation or Windows NT Server System Guide. For procedures for managing access auditing for printers, see the "Print Manager" chapter in the Windows NT Workstation or Windows NT Server System Guide. For information about auditing access to Registry keys, see the online Help for Registry Editor and Part IV, "Windows NT Registry," in the Windows NT Resource Guide.
In addition to Files, Registry Keys, and Printers, Windows NT has a number of objects that are not generally visible to or known by a typical user. Application programmers or people writing I/O device drivers might have learned about these objects in software development or device driver development kits. Normal interactive users, however, have no direct ability to affect these objects except as intended by Windows NT.
Generally speaking, these objects are used by Windows NT in a manner that makes auditing their use not very interesting. In fact, doing so can introduce so many audit entries into the security log that locating real security problems becomes considerably more difficult.
However, in some situations, it might be desirable to audit accesses to base objects. For example, where custom applications are being developed, the "users" are not just the people that interactively log on, but also the programmers who are developing applications. These programmers might be able to directly access the base objects.
Note
It is only access that is auditable, not intent. In other words, the audit log records will show that a particular user opened an object; it will not tell you what the user's intent was.
To audit the use of base objects, first set your system's audit policy to audit successful and/or failed object accesses, and then use the Registry Editor to create or assign the following Registry key value:
Hive: | HKEY_LOCAL_MACHINE\SYSTEM |
Key: | \CurrentControlSet\Control\Lsa |
Name: | AuditBaseObjects |
Type: | REG_DWORD |
Value: | 1 |
The changes take effect the next time the computer is started. You might want to update the Emergency Repair Disk to reflect these changes.
Accesses to shared base objects appear in the security log as Object Access events, like those for Files, Registry Keys, and Printers, but with different object type names and access names. For a full description of each of the base object types and their access types, refer to the Microsoft Software Developer's Network (MSDN). To receive MSDN level 2, call 800-759-5474.