On a domain controller, I see this request:
Client: 10.168.x.y:51388 Starting node: DC=abc,DC=corp,DC=xyz,DC=com Filter: (member<==>CN=usera,OU=xxx,OU=xxx,DC=abc,DC=corp,DC=xyz,DC=com) Search scope: subtree Attribute selection: name Server controls:
Visited entries:
55683
Returned entries:
14
Used indexes:
Ancestors_index:12171:N;
Pages referenced:
355546
Pages read from disk:
0
Pages preread from disk:
0
Clean pages modified:
0
Dirty pages modified:
0
Search time (ms):
344
Attributes Preventing Optimization:
member
User:
xx\usera
This request caused high CPU usage on a Win 2016 DC.
However, when I run this in ldp, it does not return any result. If I use the filer (member=…..), it returns some result. But if I use the filter (member<==>…….), it does not return anything.
I haven't seen this kind of filter before. Is this a valid filter? If it is not, how come this return 14 entries as seen in the event log?
Any help is appreciated.
I've never looked at the server logs, but I wonder if they used the LDAP_MATCHING_RULE_IN_CHAIN object identifier (OID) and that's just the way it shows up in the logs. The LDAP query you would actually use is this:
(member:1.2.840.113556.1.4.1941:=CN=usera,OU=xxx,OU=xxx,DC=abc,DC=corp,DC=xyz,DC=com)
There's more info about it here, but basically, that will search for any group that has the user as a member, but recursively. So if Group A contains Group B and Group B contains usera, then that search will return both Group A and Group B. So yes, that would be a somewhat CPU-heavy search, but also a very useful one sometimes.
So try that and see if you see the same thing in your logs when you try it.
From the perspective of the application, sometimes that kind of search is used for permissions, since, if we use my example above, if Group A is given permissions to the application, then usera should be allowed in even though they're not a direct member.
However, there are other ways to do it, depending on what the application is written in. For example, a user's Windows logon token will already contain a recursive list of the SIDs of every group they're a member of. But there might not be a logon token available when this information is needed.