在执行LDAPsearch时，我遇到了读访问uSNChanged属性的问题。
如果我使用Domain Admins组（UserA）成员的用户进行LDAPsearch，则可以看到每个用户的uSNChanged属性。
问题是，如果我使用不属于Domain Admins组的用户（UserB）进行LDAPsearch，则可以看到某些用户（UserGroupA）的uSNChanged属性，而不是某些用户（UserGroupB）。
当我查看UserGroupA中的用户并将其与UserGroupB中的用户进行比较时，我发现“安全性”选项卡中的一个重要区别。 UserGroupA中的用户具有“包含来自此对象的父级的可inheritance权限”未选中。 UserGroupB中的用户选中了该选项。
我也注意到UserGroupA中的用户是早些时候创build的用户。 UserGroupB中的用户是最近创build的用户。 这很难量化，但我估计UserGroupA和UserGroupB之间的用户创build时间的边界大约在6个月前。
什么可以导致用户创build默认为具有该安全属性选中而不是未选中？ 一段时间后（也许大约在6个月前？）我将域function级别从Windows Server 2003更改为Windows Server 2008 R2。 会有这种效果吗？ （我不能完全降级域function级来testing它。）
这个安全属性实际上是读取LDAPsearch的uSNChanged属性的问题的原因吗？ 这似乎相关，但我不确定因果关系。
我最终想要的是，所有经过身份validation的用户在进行LDAPsearch时都可以读取所有用户的uSNChanged属性。 如果我可以授予对AD组的读取访问权限，我也可以。 然后，我可以通过向该组添加成员来控制访问权限。
我不知道如何评论Craig620的答案，但他提供了一些很好的信息。 令我感到奇怪的是，您无法阅读uSNChanged，它仍应由Authenticated Users和Pre-Windows 2000 Compatible Access组（默认情况下包含Authenticated Users）读取。 默认情况下，这些组由AdminSdHolder加上受保护对象的“读取所有属性”标记。
尽pipe看起来与您的情况相反，但我在我所pipe理的环境中遇到了相反的问题，在我不知道的情况下，Authenticated Users已经从Pre-Windows 2000 Compatible Access中删除。 这样做的效果是删除大多数用户读取不受AdminSdHolder保护的帐户的大多数属性的能力，但他们能够读取受AdminSdHolder保护的帐户上的这些属性。 为了安全起见，您应该检查Pre-Windows 2000 Compatible Access的成员身份。
您可能还需要检查林中新build用户的默认ACL。 看看http://www.windowsitpro.com/article/security/defining-an-ad-object-s-default-security-descriptor并检查User类的默认ACL，而不是重新发明轮子。 这是什么决定了新创build的用户的权限。
无论哪种方式，看一看，并比较“可读”和“不可读”对象的ACL，寻找一个有另一个没有的ACE。
当用户被添加到某些特权较高的组（域pipe理员，企业pipe理员，架构pipe理员，可能是其他人（如帐户操作员））时，这些用户的inheritance位将自动禁用。 当这些用户从这些组中删除时，操作系统不会重新启用inheritance，您必须手动执行此操作。 UserB是否曾经是这样一个组的成员？
问：这个安全属性究竟是什么原因？
不明…什么明显的inheritance关系到位了？
请记住，uSNChanged不是复制的属性。 同一个对象的uSNChanged在每个域控制器上总是不同的。 请参阅“方法2” http://support.microsoft.com/kb/891995 。
我无法想象森林function级别与此有任何关系。 我怀疑显式的权限不包括已禁用inheritance的对象上具有读取属性perm的Authenticated Users。
使用AD委派。 它允许将粒度访问委托给AD中任何对象的任何属性。
在你的情况下，你需要将读权限委托给安全组或应该拥有这些权限的特定用户。
要委派控制>右键单击您想要的安全组，然后运行委派控制向导>select委派权限（或select自定义以configuration您自己的权限），将具有这些权限的用户/组添加到安全组内的对象。
这是一个例子
实施Active Directory的pipe理委派