在进行 LDAP 搜索时,我对 uSNChanged 属性的读取访问权限存在问题。
如果我使用属于域管理员组 (UserA) 成员的用户进行 LDAP 搜索,我可以看到每个用户的 uSNChanged 属性。
问题是,如果我使用不是域管理员组成员的用户(UserB)进行 LDAP 搜索,我可以看到某些用户(UserGroupA)的 uSNChanged 属性,却看不到某些用户(UserGroupB)的 uSNChanged 属性。
当我查看 UserGroupA 中的用户并将其与 UserGroupB 中的用户进行比较时,我发现“安全”选项卡中存在一个关键差异。UserGroupA 中的用户未选中“包括可从此对象的父级继承的权限”。UserGroupB 中的用户已选中该选项。
我还注意到 UserGroupA 中的用户是较早创建的用户。UserGroupB 中的用户是最近创建的用户。很难量化,但我估计 UserGroupA 和 UserGroupB 中用户创建时间的分界线大约是 6 个月前。
什么原因导致用户创建默认选中该安全属性而不是未选中?不久前(大概 6 个月前?)我将域功能级别从 Windows Server 2003 更改为 Windows Server 2008 R2。这会产生这种影响吗?(我无法降级域功能级别来测试它。)
这个安全属性是否真的是导致 LDAP 搜索中读取 uSNChanged 属性时出现问题的原因?这似乎是相关的,但我不确定是否存在因果关系。
我最终想要的是,所有经过身份验证的用户在进行 LDAP 搜索时都拥有对所有用户的 uSNChanged 属性的读取权限。如果我可以向 AD 组授予该属性的读取权限,那也行。然后我可以通过向组添加成员来控制访问权限。
答案1
我不知道该如何评论 Craig620 的回答,但他提供了一些很好的信息。让我感到奇怪的是,你无法读取 uSNChanged,而 Authenticated Users 和 Pre-Windows 2000 Compatible Access 组(默认情况下包含 Authenticated Users)应该仍然可以读取它。默认情况下,这些组在受保护的对象上被 AdminSdHolder 标记为“读取所有属性”。
虽然看起来与您的情况相反,但我在我管理的环境中遇到了相反的问题,在我不知道的情况下,经过身份验证的用户已被从 Windows 2000 之前的兼容访问中删除。这导致大多数用户无法读取不受 AdminSdHolder 保护的帐户上的大多数属性,但他们能够读取受 AdminSdHolder 保护的帐户上的这些属性。不过,为了安全起见,您可能应该检查 Windows 2000 之前的兼容访问的成员资格。
您可能还想检查林中新创建用户的默认 ACL。与其重新发明轮子,不如看看http://www.windowsitpro.com/article/security/defining-an-ad-object-s-default-security-descriptor并检查用户类默认 ACL。这决定了新创建用户的权限。
无论哪种方式,请查看并比较“可读”和“不可读”对象的 ACL,寻找其中一个对象具有而另一个对象没有的 ACE。
答案2
当用户被添加到某些高权限组(域管理员、企业管理员、架构管理员,可能还有其他权限组,如帐户操作员)时,操作系统会自动禁用这些用户的继承位。当这些用户从这些组中删除时,操作系统不会重新启用继承,您必须手动执行此操作。UserB 曾经是这样的组的成员吗?
问:这个安全属性真的是原因吗?
未知...在继承关闭的情况下,有哪些明确的权限?
请记住,uSNChanged 不是复制属性。同一对象的 uSNChanged 在每个域控制器上始终不同。请参阅此处的“方法 2”http://support.microsoft.com/kb/891995。
我无法想象森林功能级别与此有任何关系。我怀疑显式权限不包括对禁用继承的对象具有读取属性权限的经过身份验证的用户。
答案3
使用 AD 委派。它允许委派对 AD 中任何对象的任何属性的细粒度访问。
在您的情况下,您需要将读取权限委托给安全组或应该具有此类权限的特定用户。
要委派控制 > 右键单击您想要的安全组并运行委派控制向导 > 选择要委派的权限(或选择自定义来配置您自己的权限),将具有这些权限的用户/组添加到安全组内的对象。
以下是一个例子