In the case of auditing NTFS file or directory access, the administrator can further refine the audit policy by selecting the files or directories that NT should monitor. In doing so, the administrator also specifies which users or groups are subject to auditing and which actions on their part (read, write, delete, execute, change permissions, or take ownership) will generate an audit message. The administrator can request an audit message if attempts to perform these actions are successful, unsuccessful, or both. When the system logs a security event, it includes two indicators in the log entry: a primary ID, which identifies the actual process that generated the event; and an impersonation ID, which denotes the user on behalf of which the process was acting. In the case of an access violation or attempted violation, the administrator can more easily determine who was behind it and what application he or she was using. Many audit log messages also contain a handle ID that helps correlate a group of actions on the same object over a period of time. For example, when a user opens and then closes a file, the audit events carry the same handle ID, enabling the administrator to determine how long the user had the file open.
|
|
|
|
|
|
|
|