EventID 566 unixUserPassword

[Scott2580]

After loading the R2 Schema in our production forest, we are gettiing multiple Audit Failure 566 events from users and workstations against the unixUserPassword attrib on Users and Group objects. After we upgraded from 2000 to 2003, we have anonymous logon and everyone and auth users in our Pre-Windows 2000 compatible group. I have checked that one of the error generators has read access to the specific objext/attrib. It is happening in other or maybe all domains within our Forest. So does anyone has any ideas?

Event Type: Failure Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 566
Date: 24/11/2006
Time: 10:54:55
User: London Workstation$
Computer: Domain Controller$
Description:
Object Operation:
Object Server: DS
Operation Type: Object Access
Object Type: user
Object Name: CN=UserName,OU=Users,OU=LON,OU=Europe,DC=Our
Domain,DC=Our Company,DC=com
Handle ID: -
Primary User Name: Domain Controller$
Primary Domain: Our Domain
Primary Logon ID: (0x0,0x3E7)
Client User Name: London Workstation$
Client Domain: Our Domain
Client Logon ID: (0x1,0x51625D32)
Accesses: Control Access

[Rawko]

The problem for his failure audits are happening because the unixUserPassword attribute search flag is marked as 128. Windows Server 2003 SP1 has a way to mark an attribute as confidential. You will need to 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.

[John Rolstead]

From the article, it states:
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.

See this too: http://support.microsoft.com/default...b;EN-US;922836

So the failure audit is generated because Read_Property has been granted to the attribute that has been set as confidential. By default, the Schema reveals that the User object classs does not assign this right to Authenticated Users. So the permissions have been modified, probably at domain level to grant Read_Property to the attributes listed in the Properties: section.

I did the same thing, granted Read (Standard Set: Read All Properties, List Contents, Read Permissions) to a group of service accounts and now those accounts show in security log with failure audit trying to read any attribute flaged as confidential.

My list of attributes so marked are: msPKIAccountCredentials, msPKIDPAPIMasterKeys, msPKIRoamingTimeStamp, unixUserPassword

This blog outlines the solution. The fix is to grant Control Access as well as Read_Property. Note that to use LDP to change the security, it must be versoin from Windows Server 2003 R2 Install Disk.

DSACLS syntax to set this permission on container or object is:
dsacls <dn> /G <security principal>:ca;<attrName>;