奇怪的 ldap 过滤器 (member<==>CN=usera,OU=xxx,OU=xxx,DC=abc,DC=corp,DC=xyz,DC=com)
Weird ldap filter (member<==>CN=usera,OU=xxx,OU=xxx,DC=abc,DC=corp,DC=xyz,DC=com)
在域控制器上，我看到这个请求：
客户：
10.168.x.y:51388
起始节点：
DC=abc,DC=corp,DC=xyz,DC=com
筛选：
(会员<==>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
搜索时间（毫秒）：
344
阻止优化的属性：
会员
用户：
xx\usera
此请求导致 Win 2016 DC 上 CPU 使用率过高。
然而，当我在 ldp 中 运行 这个时，它 return 没有任何结果。如果我使用文件管理器 (member=…..)，它 return 会产生一些结果。但是，如果我使用过滤器 (member<==>.......)，它不会 return 任何东西。
我以前没见过这种滤镜。这是一个有效的过滤器吗？如果不是，为什么会在事件日志中看到 return 14 个条目？
感谢任何帮助。
我从未查看过服务器日志，但我想知道他们是否使用了 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)
有更多关于它的信息 here，但基本上，这将搜索以递归方式将用户作为成员的任何组。因此，如果 Group A 包含 Group B 而 Group B 包含 usera，则该搜索将 return 同时包含 Group A 和 Group B。所以是的，这将是一个有点 CPU 的搜索，但有时也是一个非常有用的搜索。
所以尝试一下，看看您在尝试时是否会在日志中看到相同的内容。
从应用程序的角度来看，有时这种搜索用于权限，因为，如果我们使用上面的示例，如果 Group A 被授予应用程序权限，那么 usera即使他们不是 直接 成员也应该被允许。
但是，还有其他方法可以做到这一点，具体取决于编写的应用程序。例如，用户的 Windows 登录令牌将已经包含他们所在的每个组的 SID 的递归列表重新成为会员。但是当需要此信息时可能没有可用的登录令牌。
在域控制器上，我看到这个请求：
客户： 10.168.x.y:51388 起始节点： DC=abc,DC=corp,DC=xyz,DC=com 筛选： (会员<==>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
搜索时间（毫秒）：
344
阻止优化的属性：
会员
用户：
xx\usera
此请求导致 Win 2016 DC 上 CPU 使用率过高。
然而，当我在 ldp 中 运行 这个时，它 return 没有任何结果。如果我使用文件管理器 (member=…..)，它 return 会产生一些结果。但是，如果我使用过滤器 (member<==>.......)，它不会 return 任何东西。
我以前没见过这种滤镜。这是一个有效的过滤器吗？如果不是，为什么会在事件日志中看到 return 14 个条目？
感谢任何帮助。
我从未查看过服务器日志，但我想知道他们是否使用了 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)
有更多关于它的信息 here，但基本上，这将搜索以递归方式将用户作为成员的任何组。因此，如果 Group A 包含 Group B 而 Group B 包含 usera，则该搜索将 return 同时包含 Group A 和 Group B。所以是的，这将是一个有点 CPU 的搜索，但有时也是一个非常有用的搜索。
所以尝试一下，看看您在尝试时是否会在日志中看到相同的内容。
从应用程序的角度来看，有时这种搜索用于权限，因为，如果我们使用上面的示例，如果 Group A 被授予应用程序权限，那么 usera即使他们不是 直接 成员也应该被允许。
但是，还有其他方法可以做到这一点，具体取决于编写的应用程序。例如，用户的 Windows 登录令牌将已经包含他们所在的每个组的 SID 的递归列表重新成为会员。但是当需要此信息时可能没有可用的登录令牌。