Windows Security Log Event ID 560
Operating Systems Windows Server 2000
Windows XP
Windows Server 2003
CategoryObject Access
Type Success
Failure
Corresponding events
in Windows 2008
and Vista
4656  
Discussions on Event ID 560
Missing Handle (-) Causing Failure Audit
What is Object Server?
How to track user modifications and accesses to folders and files
Wmiprvse.exe 560 Errors
Root cause of 560 failed object access attempts

560: Object Open

On this page

Events of this category allow you to track failed and successful attempts to access files and other Windows objects.

Event 560 is logged whenever a program opens an object where:

- the type of access requested has been enabled for auditing in the audit policy for this object

- the result (success/failure) has been enabled for auditing for this object

- the account the program is running under is included in the users and/or groups specified for auditing in the audit policy for this object 

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, and  both 565 and 566 for Windows 2003.

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.

  • Object Server:
  • Object Type:
  • Object Name:
  • New Handle ID:
  • Operation ID
  • Process ID:
  • Primary User Name:
  • Primary Domain:
  • Primary Logon ID:
  • Client User Name:
  • Client Domain:
  • Client Logon ID:
  • Accesses
  • Privileges

Windows 2003 fields:

  • Object Server:
  • Object Type:
  • Object Name:
  • New Handle ID:
  • Operation ID:
  • Process ID:
  • Primary User Name:
  • Primary Domain:
  • Primary Logon ID:
  • Client User Name:
  • Client Domain:
  • Client Logon ID:
  • Accesses 
  • Privileges
  • Restricted Sid Count:
  • Access Mask:

Top 10 Windows Security Events to Monitor

Object Open:
Object Server:Security
Object Type:File
Object Name:C:\ConfidentialFiles\ ProjectPlan.doc.txt
New Handle ID:1468
Operation ID:{0,1023441}
Process ID:1688
Windows Server 2003 adds this field:
Image File Name:C:\WINDOWS\ system32\ notepad.exe
All versions of Windows log these fields:
Primary User Name:administrator
Primary Domain:ELMW2
Primary Logon ID:(0x0,0x804C2)
Client User Name:-
Client Domain:-
Client Logon ID:-
AccessesDELETE
READ_CONTROL
ReadAttributes
Privileges-
Windows Server 2003 adds these fields:
Restricted Sid Count:0
Access Mask:0x10080

Keep me up-to-date on the Windows Security Log.
Email*:
*We will NOT share this



Training for the Windows Security Log