I have an issue with read access to the uSNChanged property when doing LDAP searches.

If I do an LDAP search with a user that is a member of the Domain Admins group (UserA), I can see the uSNChanged property for every user.

The problem is that if I do an LDAP search with a user (UserB) that is not a member of the Domain Admins group, I can see the uSNChanged property for some users (UserGroupA) and not for some users (UserGroupB).

When I look at the users in UserGroupA and compare them to the users in UserGroupB, I see a crucial difference in the "Security" tab. The users in UserGroupA have the "Include inheritable permissions from this object's parent" unchecked. The users in UserGroupB have that option checked.

I also noticed that the users in UserGroupA are users that were created earlier. The users in UserGroupB are users created recently. It's difficult to quantify, but I estimate the border between creation time between the users in UserGroupA and UserGroupB is about 6 months ago.

What can cause the user creation to default to having that security property checked as opposed to unchecked? A while back (maybe around 6 months ago?) I changed the domain functional level from Windows Server 2003 to Windows Server 2008 R2. Would that have had this effect? (I can't exactly downgrade the domain functional level to test it out.)

Is this security property actually the cause of the issue with read access to the uSNChanged property on LDAP searches? It seems correlated, but I'm not sure about causation.

What I want in the end is for all authenticated users to have read access to the uSNChanged property for all users when doing an LDAP search. I would also be OK if I could grant read access for that property to an AD group. Then I can control access by adding members to the group.


I can't figure out how to comment on Craig620's answer, but he offered some good info. Something that strikes me as odd is that you are unable to read uSNChanged, which should still be readable by Authenticated Users and the Pre-Windows 2000 Compatible Access group (which by default contains Authenticated Users). Those groups by default are stamped by AdminSdHolder with "Read all properties" on protected objects.

Although it appears to be the opposite of your situation, I ran into the opposite issue in an environment I managed where, unbeknownst to me, Authenticated Users had been removed from Pre-Windows 2000 Compatible Access. This had the effect of removing most users' ability to read most properties on accounts not protected by AdminSdHolder, but they WERE able to read those properties on AdminSdHolder-protected accounts. Just to be safe though, you should probably check the membership of Pre-Windows 2000 Compatible Access.

You may also want to check the default ACL for newly created users in the forest. Rather than reinvent the wheel, take a look at http://www.windowsitpro.com/article/security/defining-an-ad-object-s-default-security-descriptor and check the User class default ACL. That is what determines a newly created user's permissions.

Either way, take a look and compare the ACLs on "readable" and "nonreadable" objects looking for ACEs that one has that the other doesn't.

  • I checked the Pre-Windows 2000 Compatible Access group and the only member was the computer I'm using as my Issuing CA (!?). I added "Everyone" and now everyone can see the uSNChanged paramater. – Tom Ligda Dec 3 '12 at 20:25

When a user is added to certain highly privileged groups (domain admins, enterprise admins, schema admins, possibly others like account operators) the inheritance bit for those users is automatically disabled by the OS. When those users are removed from the those groups, the inheritance is NOT re-enabled by the OS, you must do that manually. Was UserB ever a member of a group like that?

Q: Is this security property actually the cause?
Unknown... what explicit perms were in place with inheritance off?

Remember that uSNChanged in not a replicated attribute. The uSNChanged for the same object will always be different on each domain controller. See "method 2" here http://support.microsoft.com/kb/891995.

I can't imagine Forest Functional level having anything to do with this. I suspect the explicit perms did not include Authenticated Users having Read properties perm on the object where inheritance was disabled.


Use AD Delegation. It allows delegating granular access to any of the properties of any object in AD.

In your case, you need to delegate read permission to security group or particular users which should have such permissions.

To delegate control > right-click on Security group you want and run delegate control wizard > select permission to delegate (or choose custom to configure your own), add users/groups who will have these permissions to objects inside Security Group.

Here is an example

Implementing Active Directory Delegation of Administration

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.