Event ID/Source search
Keyword searchExample: Windows cannot unload your registry file
Event ID: 566 Source: Security
|Type: Failure Audit|
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
Access Mask: 0x100
|English: Request a translation of the event description in plain English.|
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".
|Private comment: Subscribers only. See example of private comment|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (1) - More links...|
Send comments or solutions
- Notify me when updated