EventID 4662 (Windows 2012) or EventID 566 (Windows 2003) – Type: Failure Audit

When using Umbrella Insights, you receive Windows 2003 Security Event ID 566 or Windows 2012 Security Event ID 4662 in the Event Viewer Security log.

This article describes what these events mean and what action you could take.  These events could be expected to occur on Domain Controllers or a member server running as part of the Umbrella Insights deployment.

Note:  These events are to be expected and are normal.  The preferred and supported action is to do nothing and ignore these events.

Event ID: 566
Source: Security
Category: Directory Service Access
Type: Failure Audit


Object Operation:

Object Server:  DS
Operation Type: Object Access
Object Type:    user

Object Name:   CN=vipan,OU=MyOU,DC=windowstechno,DC=Local


Handle ID:        –
Primary User Name:     DC01$
Primary Domain:          windowstechno
Primary Logon ID:        (0x0,0x3E7)
Client User Name:        COMPUTER1$
Client Domain:  DOMAIN1
Client Logon ID:           (0x0,0x19540114)

Accesses:         Control Access

Private Information

Default property set


Additional Info:
Additional Info2:
Access Mask:   0x100

Or you receive the following Windows 2008 Event Security ID 4662

Event ID: 4662
Type: Audit Failure
Category: Directory Service Access


An operation was performed on an object.

Subject :

Security ID:                  windowstechno\COMPUTER1$
Account Name:            COMPUTER1$
Account Domain:          DOMAIN1

Logon ID:                     0x3a26176b


Object Server:              DS
Object Type:                user
Object Name:              CN=vipan,OU=MyOU,DC=windowstechno,DC=Local


Handle ID:                    0x0


Operation Type:           Object Access
Accesses:                     Control Access
Access Mask:               0x100

Properties:                    —




Windows 2008 introduced a new property set called Private Information that includes the msPKI* properties. By design, these properties are secured in such a manner that only the SELF object can access them.  You can use the DSACLS command to verify the permissions on the object as needed.

Cursory investigation may lead you to believe this audit event is being caused by an attempt to write to these restricted properties. This is evident by the fact these events occur under the default Microsoft audit policy that only audits changes (writes), and does not audit attempts to read information from Active Directory.

However, this is not the case, the audit event clearly lists the permission being requested as Control Access (0x100).  Unfortunately, you can not grant the CA (Control Access) permission to the Private Information property set.



You can safely ignore these messages. This is by design.

It is not recommended that you take any action to prevent these events from appearing.  However, the following are presented as options should you choose to implement them. Neither workaround is recommended: use at your own risk.



Method 1

Disable all auditing in Active Directory by disabling the Directory Service auditing setting in the default Domain Controller policy.

Method 2

The underlying process that manages the Control Access permission utilizes the searchFlags attribute that is assigned to each property (ie: msPKIRoamingTimeStamp). searchFlags is a 10 bit access mask. It uses bit 8 (counting from 0 to 7 in a binary access mask = 10000000 = 128 decimal) to implement the concept of Confidential Access.  You can manually modify this attribute in the AD Schema and disable the Confidential Access of these properties.  This will then prevent the failure audit logs from being generated.

To disable Confidential Access for any property in AD use ADSI Edit to attach to the Schema naming context on the DC holding the Schema Master Role. Find the appropriate properties to modify, their name may be slightly different than what is shown in Event ID 566 or 4662.

To determine the correct value to enter subtract 128 from the current searchFlags value, and enter the result as the new value of searchFlags, thus 640-128 = 512. If the current value of searchFlags is < 128 do nothing, you may have the wrong property or Confidential Access is not causing the audit event.

Do this for each property listed in the Event ID 566 or 4662 description.

Force replication of the Schema Master to the other domain controllers, then check for new Events.

Modify the domain audit policy not to audit failures on these properties:

The downside to this method is performance may be degraded due to the high number of audit entries that need to be added.


More Information:
Translating GUID to objects names is easy using google or another search engine.  Here is an example of how to search using google.

Example: site:microsoft.com 91e647de-d96f-4b70-9557-d63ff4f3ccd8


If you have any questions feel free to contact me on admin@windowstechno.com also follow me on facebook @windowstechno to get updates about new blog posts.

How useful was this post?

Click on a star to rate it!

Leave a Reply