Event ID 560
In Windows, a program first opens an object - requesting certain
types of access (i.e. read and/or write). Windows compares
the objects ACL to the program's access token which identifies
the user and groups to which the user belongs. The open may
succeed or fail depending on this comparison. Regardless, Windows
then checks the audit policy of the object. If the policy enables
auditing for the user, type of access requested and the success/failure
result, Windows records generates event 560.
In the case of failed access attempts, event 560 is the only event
recorded. Note that the accesses listed include all the accesses
requested - not just the access types denied. If the access attempt succeeds, later in the log you will
find an event ID 562 with the same handle ID which indicates when
the user/program closed the object.
One action from a user standpoint may generate many object
access events because of how the application interacts with
the operating system. This especially true with Windows Explorer
and MS Office applications.
Event 560 is logged for all Windows object where auditing
is enabled except for Active Directory objects. Windows objects
that can be audited include
files, folders, registry keys, printers and services. To audit access to Active Directory objects such as users,
groups, organizational units, group policy objects, domains,
sites, etc see event IDs 565 for Windows 2000, 565 for Windows 2003, and 566.
Object Type: specifies whether the object is a file, folder,
registry key, etc.
Object Name: identifies the object of this event - full path
name of file.
New Handle ID: When a program opens an object it obtains a
handle to the file which it uses in subsequent operations on
the object. You can link this event to other events involving
the same session of access to this object by the program by
looking for events with the same handle ID.
Operation ID: unkown
Process ID: matches the process ID logged in event 592 earlier
in log. Prior to W3, to determine the name of the program used
to open this object, you must find the corresponding event 592.
Image File Name: full path name of the executable used to
open the object. W3 only.
Primary fields: When user opens an object on local system
these fields will accurately identify the user. When a user
at a workstation opens an object on a server (such as through
a shared folder) these fields will only identify the server
program used to open the object on behalf of the remote user.
See client fields.
Client fields: Empty if user opens object on local workstation.
When user opens an object on a server from over the network,
these fields identify the user.
Logon IDs: Match the logon ID of the corresponding event 528 or 540.
Access: Identify the permissions the program requested. This
includes both permissions enabled for auditing on this object's
audit policy as well as permissions requested by the program
but not specified for auditing. The accesses listed in this
field directly correspond to the permission available on the
corresponding type of object.
In the case of successful object opens, Accesses documents
the types of access the user/program succeeded in obtaining
on the object. However event 560 does not necessarily indicate
that the user/program actually exercised those permissions.
For instance a user may open an file for read and write access
but close the file without ever modifying it. Prior to XP and
W3 there is no way to distinguish between potential and realized
access. Starting with XP Windows begins logging operation based
auditing. See event 567.
Write_DAC indicates the user/program attempted to change the
permissions on the object.
This is just a fraction of the wealth of information available only in Randy Franklin Smith's eBook, The Windows Server Security Log Revealed.
|
