怪异的ldap过滤器(member<==>CN=usera、OU=xxx、OU=xxx、DC=abc、DC=corp、DC=xyz、DC=com)

Question

在域控制器上，我看到以下请求：

Client: 10.168.x.y:51388起始节点: DC=abc、DC=corp、DC=xyz、DC=com过滤器：(member<==>CN=usera、OU=xxx、OU=xxx、DC=abc、DC=corp、DC=xyz、DC=com)搜索范围:子树属性选择:名称服务器控件：

访问条目: 55683返回条目:14个已使用的索引: Ancestors_index:12171:N；引用的页面: 355546页从磁盘读取:0页从磁盘预读:0干净页修改:0脏页修改:0搜索时间(ms)：344个属性防止优化:成员

用户:xx\

这一请求导致Win 2016 DC的CPU使用率过高。

但是，当我在ldp中运行这个程序时，它不会返回任何结果。如果我使用文件处理程序(member=…))，它返回一些结果。但是如果我使用过滤器(member<==>……))，它不返回任何东西。

我以前从没见过这种过滤器。这是有效的过滤器吗？如果不是，为什么这个返回事件日志中看到的14个条目？

任何帮助都是非常感谢的。

Answer 1

我从来没有看过服务器日志，但我想知道它们是否使用了LDAP_MATCHING_RULE_IN_CHAIN对象标识符(OID)，而这正是它在日志中显示的方式。您将实际使用的LDAP查询如下：

(member:1.2.840.113556.1.4.1941:=CN=usera,OU=xxx,OU=xxx,DC=abc,DC=corp,DC=xyz,DC=com)

这里有更多关于它的信息，但基本上，它将搜索任何以用户为成员但以递归方式存在的组。因此，如果Group A包含Group B，Group B包含usera，那么该搜索将返回Group A和Group B。所以是的，这将是一个有点CPU的搜索，但有时也非常有用。

所以，尝试一下，看看在您的日志中是否看到了相同的东西。

从应用程序的角度来看，有时会使用这种搜索权限，因为，如果我们使用上面的例子，如果Group A被授予应用程序的权限，那么即使它们不是直接成员，也应该允许usera进入。

但是，根据应用程序是用什么编写的，还有其他方法可以做到这一点。例如，用户的Windows登录令牌将包含它们所属的每个组的小岛屿发展中国家的递归列表。但是，当需要此信息时，可能没有可用的登录令牌。