Event IDs 560 and 562 appear many times in the security event log

After you configure Group Policy or Local Security Policy to audit access to an object, many events that are similar to the following events appear in the security event log:

Event Source: Security
Event Category: Object Access
Event ID: 560
Date: date
Time: time
Type: Success
User: EXAMPLE\username
Computer: computer_name
Description:
Object Open:
Object Server: Security
Object Type: Object_Type
Object Name: Object_Type
New Handle ID: 104
Operation ID: {0,252360}
Process ID: 1156
Primary User Name: username
Primary Domain: EXAMPLE
Primary Logon ID: (logon_ID)
Client User Name:
Client Domain:
Client Logon ID:
Accesses
<List of Accesses>
Privileges

Event Source: Security
Event Category: Object Access
Event ID: 562
Date: date
Time: time
Type: Success
User: EXAMPLE\username
Computer: computer_name
Description:
Handle Closed:
Object Server: Security
Handle ID: 104
Process ID: 1156

These events appear if you have not configured the security access control list (SACL) on the object that you are auditing. The events also appear if you have configured the SACL, but not for all the listed accesses. For example, these events are logged when a user or a program reads a registry subkey, and you have not selected the Read Control or the Query Value check box in the auditing entry for that registry subkey.

Note For additional information about how to configure auditing, see the "More Information" section.

This issue may occur if one of the following conditions is true:

• You enable the Audit the access of global system objects Local Security Policy setting. If you enable this setting, many audit events will be generated. These events will typically be source security events with Event ID 560, where the object type is event, mutant, process, section, semaphore, thread, or token. These events are of interest only to a system developer. Typically, the Audit the access of global system objects Local Security Policy setting is not enabled.
• You enable auditing on a domain controller. When you enable auditing on a domain controller, audit events will be generated that typically contain references to the following object types:
  • SAM_ALIAS
  • SAM_GROUP
  • SAM_USER
  • SAM_DOMAIN
  • SAM_SERVER
  These events indicate that the Security Accounts Manager (SAM) objects have security access control lists (SACL) and that there is much SAM activity occurring. Typically, these events occur only on a domain controller.
• You use an application that opens audited objects too frequently or that opens audited objects with greater access than the application requires. For example, the application may request full control access when the application requires only read access. When this behavior occurs, events may be generated where the referenced process is always the same application.

To resolve this issue, use one of the following methods:

Method 1

Disable the Audit the access of global system objects Local Security Policy setting if you have previously enabled this setting. To do this, follow these steps:

1. Click Start, click Run, type gpedit.msc, and then click OK.
2. Locate the following entry:
   Console Root\Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
3. Double-click the Audit the access of global system objects policy, click Disabled under Local Policy, and then click OK.
4. On the Console menu, click Exit, and then restart the computer.

Method 2

Use the ADSI Edit snap-in to remove the auditing entries on the SACL for a SAM object if you have enabled auditing on a domain controller. To do this, follow these steps.

Note The ADSI Edit snap-in is located in the Support folder on the Windows 2000 installation CD-ROM.

Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

1. Log on to the domain controller by using an account that has Domain Administrator permissions.
2. Click Start, click Run, type adsiedit.msc, and then click OK.
3. In the ADSI Edit management console, right-click ADSI Edit, and then click Connect to.
4. In the Connection dialog box, make sure that the Distinguished Name option is selected, and then type the following in the Distinguished Name field:
   
   CN=Server,CN=System,DC=Domain_Name,DC=Domain_Extensionaceholder throughout these steps.
5. Select the Default (Domain or Server that you logged in to) option, and then click OK.
6. In the ADSI Edit management console, right-click the CN=Server,CN=System,DC=Domain_Name,DC=Domain_Extension folder, and then click Properties.
7. In the CN=Server,CN=System,DC=Domain_Name,DC=Domain_Extension Properties dialog box, click the Security tab.
8. Click Advanced, and then click the Auditing tab.
9. Click to clear the Allow inheritable auditing entries from parent to propagate to this object check box.
10. When you are prompted with the following message, click Remove.
    
    
    You are preventing any inheritable auditing entries from propagating to this object. What do you want to do?
11. Click OK two times to save the setting and to close the CN=Server,CN=System,DC=Domain_Name,DC=Domain_Extension Properties dialog box.

Method 3

Configure the custom application to open audited objects only as required. For example, configure the custom application to request only the minimum access that is required. If the custom application requires only read access for a specific object, assign only read access. In this case, full control access is not required.

Windows 2000 implements auditing based on the access that is requested by a user or by a program. If a user or a program accesses an object by using an account that has an auditable level of access to the object, Windows generates the corresponding audit event. For example, if you configure a program with write access to an object, and you have configured auditing for write events, a write audit event is generated when that program accesses the object. This behavior occurs even if the program does not perform a write operation to a registry subkey. In this scenario, this audit event is generated because the program has the potential to write to the object.

Windows implements this auditing method to maintain compliance with the Common Criteria certification standards and, previously, the C2 certification standards. For additional information about C2 audit requirements, see A Guide to Understanding Audit in Trusted Systems. To see this guide, visit the following Web page: "Section 6.1.1 Auditable Events" in this guide contains the following two auditable events:

• Introduction of objects into a user's address space
• Deletion of objects from a user's address space

In Windows, Event ID 560 represents the first event, and Event ID 562 represents the second event.

For additional information about the Common Criteria certification standards, visit the following Microsoft Web site: For additional information about how to audit registry keys, click the following article number to view the article in the Microsoft Knowledge Base: For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base: Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.