我有一个Debian Squeeze系统，它使用libnss-ldap绑定到2008 Active Directory域控制器来查找用户和组。一切正常，除了某些原因，在Domain Admins，Enterprise Admins或Schema Admins组中的任何人都没有获得正确的组成员身份。他们只获得* Admin组，没有其他人（除非有适用的本地组，显示）。
奇怪的是，“getent group”显示了用户的所有正确的组成员身份，但“id”或“groups”（以用户身份运行时）则没有。我们使用域组进行sudo访问，并且该用户无法使用sudo，因为它无法看到组成员身份。删除* Admin成员资格后，查找工作正常。
我怀疑这可能是AD安全功能，但我们使用nss-ldap的FreeBSD系统，这些用户的组成员资格正确解析。日志中没有任何内容可以指示为什么这些查找不会返回正常结果，而且我无法通过Google找到任何内容来帮助了解情况。是否有其他人在Debian中使用libnss-ldap连接到可以尝试确认此行为的AD？
编辑：我已经确认使用ldapsearch AD正在返回正确的结果。我也停止了nscd以确保它没有干扰。 Domain Admins中的任何用户只能看到他的主要组，本地组和Domain Admins。
答案 0 :(得分：1)
我也遇到过这个问题。
我最近在18个月前发现了它。这是Microsoft的安全功能。有一项服务每小时运行一次，并从LDAP搜索中删除管理员。如果您以匿名方式进行查询，您将收到1小时的正确答案。一小时后你什么也得不到。如果您以域用户身份登录，您将收到正确的信息。这就是为什么你得到不同的结果。
我现在还没记住服务名称，但我现在正在搜索它。我大约18个月前在微软科技网上发现它，但到现在为止，我还记得它。
重点是答案的唯一答案是
禁用该服务，它会执行许多其他安全项目，因此这不是一个好主意。
将LDAP搜索更改为在域用户登录下运行（我们已在某些用户上执行此操作）
为每个管理员创建一个虚假的重复联系人，其中包含相同的信息。这可能是最容易和最快的，但最容易随着时间的推移而产生错误的信息。
此安全功能的合理性在于隐藏所有域管理员免受随机匿名搜索，因此他们的凭据不会受到百科全书密码攻击的影响。
凯文·托马斯
答案 1 :(得分：1)
我的答案已删除，但问题是，实际上是http://support.microsoft.com/kb/976063中描述的UAC。问题是，在DC上启用UAC时，Domain Admins实际上存在两种状态。一个是域管理员组的成员（即，UAC'影子'用户），另一个是普通用户。当使用LDAP查询时，DC似乎仅返回前者。通过创建新组，使该组成为Domain Admins的成员而不是帐户本身，并将帐户放入新组，问题得以解决。