EventID 566 unixUserPassword

Hi!
Since loading the R2 Schema in our production forest, we are experiencing
multiple Audit Failure 566 events from users AND workstations against the
unixUserPassword attrib on Users and Group objects. Since we upgraded from
2000 - 2003, we have anonymous logon, everyone and auth users in our
Pre-Windows 2000 compatible group (which still has read access to every
object/attrib in the domains).
I have verified that one of the error generators has read access to the
specific object/attrib.
This is occuring in other (maybe all) Domains within our Forest.
Currently, we are not using this attrib, so it is blank/not set.
Obviously, the security event log on the Domain Controllers is the source of
the event.

So, any pointers ;-)

Thanks
G

For Example

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

Properties:
---
Default property set
unixUserPassword
user

Additional Info:
Additional Info2:
Access Mask: 0x100

I could've put this as a comment instead of a question before anyone mentions
it....

Anyway, the answer...
##########################

The reason the failure audits are happening is because 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 between 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. KB 922836 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.

The following KB contains more information: 922836 How to mark an attribute
as confidential in Windows Server 2003 Service Pack 1 -
<http://support.microsoft.com/default...b;EN-US;922836


Our MS Contact provided this answer. :-)



I am experiencing the exact same issue... from several sources that are binding via ldap for authentication.

[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>;