Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 566 Source: Security

Object Operation:
Object Server: DS
Operation Type: Object Access
Object Type: user
Object Name: CN=userOU=NJ_USERSOU=userOU=userDC=mformationDC=com
Handle ID: -
Primary User Name: SERDC01'$
Primary Domain: MFORMATION
Primary Logon ID: (0x00x3E7)
Client User Name: jdoe
Client Domain: MFORMATION
Client Logon ID: (0x00x133556D4)
Accesses: Control Access

Default property set

Additional Info:
Additional Info2:
Access Mask: 0x100
The same event is recorded for any failure to set various types of properties used within Active Directory so the administrator should pay particular attention to the part of the event description that lists the properties that caused the failure audit. For example, property "unixUserPassword" respresents contains a user password that is compatible with a UNIX system. This information is stored in Active Directory and this failure audit indicates that a request to update or access this information has been denied. Obviously, the troubleshooting approach for this should be different when the same event id is recorded when a DNS server fails to update one of its records (and dnsRecord would be listed as one of the properties). Another part of the event description that is relevant is the "Accesses" information which indicates the type of operation that was attempted against the properties specified.
From a newsgroup post: "The reason the failure audits are happening is that the unixUserPassword attribute search flag is marked as 128. Windows Server 2003 SP1 introduces a way to mark an attribute as confidential. To do this, you modify the value of the searchFlags attribute in the schema. The searchFlags attribute value contains multiple bits that represent various properties of an attribute. For example, if bit 1 is set, the attribute is indexed. Bit 7 (128) designates the attribute as confidential. When Windows Server 2003 SP1 is installed and after Active Directory performs a read access check, Active Directory checks for confidential attributes. If confidential attributes exist and if READ_PROPERTY permissions are set for these attributes, Active Directory will also require CONTROL_ACCESS permissions for the attributes or for their property sets.

The R2 update changed the searchflag attribute. You have the following options:

1. Set Directory Service Access Auditing to no auditing to remove the audit entries from the security event log.
2. In ADSIEDIT go into the SCHEMA partition - UnixUserPassword - under the attributes of search flags change from 128 to 0 then Force replication.

Monitor for the re-appearance of the 566 event error.

Why was SearchFlags changed from 0 to 128 for unixUserPassword by the R2 Schema?
The released version of the R2 schema includes this 128 value - this is most likely because it is a password and required confidentiality. The 128 search flag attribute on domain controllers running Windows Server 2003 with SP1, make an attribute confidential. By default, only members of the built-in Administrators group can read a confidential attribute.

What does a 128 value mean for Search-Flags on an attribute?
Bit 7 (128) designates the attribute as confidential. ME922836 explains confidential attributes and what this affects.

What are the potential ramifications of changing Search-Flags from 128 to 0?
Since its a password attribute, it was set as confidential in R2, and setting it back to 0, makes it viewable for everyone, which itself is a bad ramification. All users can get to the attribute...which may not be recommended, since it is a password.

See ME922836 for information on how to mark an attribute as confidential in Windows Server 2003 Service Pack 1".

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to



Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.