Splunk Search

How to LDAPGROUP filter by MEMBER_TYPE?

ddetlef
Explorer

I am successfully using some simple LDAPSEARCH + LDAPGROUP searches to produce membership lists for various AD groups.

Ex.

 

 

| ldapsearch search="(&(objectClass=Group)(cn=Remote Desktop Users)"
| table cn,distinguishedName
| ldapgroup
| table cn,member_name,member_type

 

 

The searches work, but always show me all possible membership types (DIRECT, NESTED, etc.)

I would like to filter my end results so that only DIRECT members are returned.

I've tried inserting a | WHERE clause after the LDAPGROUP or final table command, but it just returns an empty set.

I'm clearly not quite understanding how to pipeline output correctly.  Any help is much appreciated.
  

Labels (1)
0 Karma
1 Solution

richgalloway
SplunkTrust
SplunkTrust

That table should have been in the OP since it clarifies the problem.  It appears that ldapgroup creates multivalue fields that standard where/search operators can't handle.  The solution is to expand the multivalue fields before filtering them.  To retain the relationship between member_name and member_type, we'll use mvzip to pair them up before expanding them.

| ldapsearch search="(&(objectClass=Group)(cn=Remote Desktop Users)"
| table cn,distinguishedName
| ldapgroup
``` Combine member_name and member_type
| eval member_name_type=mvzip(member_name, member_type, "#")
``` Put each member into a separate event ```
| mvexpand member_name_type
``` Break the member field apart again ```
| eval member_name_type = split(member_name_type, "#")
| eval member_name=mvindex(member_name_type,0), member_type=mvindex(member_name_type,1)
| where member_type="DIRECT"
| table cn,member_name,member_type

 

---
If this reply helps you, Karma would be appreciated.

View solution in original post

richgalloway
SplunkTrust
SplunkTrust

What where command have you used?  It should be something like this.

| ldapsearch search="(&(objectClass=Group)(cn=Remote Desktop Users)"
| table cn,distinguishedName
| ldapgroup
| where member_type="DIRECT"
| table cn,member_name,member_type

Have you tried a search command?

| ldapsearch search="(&(objectClass=Group)(cn=Remote Desktop Users)"
| table cn,distinguishedName
| ldapgroup
| search member_type="DIRECT"
| table cn,member_name,member_type

If both of those fail then perhaps the ldapgroup command is unable to get the member_type information.  Try enabling logging to see what is happening.

| ldapsearch search="(&(objectClass=Group)(cn=Remote Desktop Users)"
| table cn,distinguishedName
| ldapgroup debug=1 logging_level=DEBUG
| table cn,member_name,member_type

Then search

index=_internal source=*SA-ldapsearch.log
---
If this reply helps you, Karma would be appreciated.
0 Karma

ddetlef
Explorer

Thanks @richgalloway ,

As I understand it, LDAPGROUP is what is generating the MEMBER_TYPE information.

https://docs.splunk.com/Documentation/SA-LdapSearch/3.0.7/User/Theldapgroupcommand

From your suggestions, I tried both 

  • | ldapgroup | where member_type="DIRECT"
  • | ldapgroup | search member_type="DIRECT"

and both of them produce the same result as my original search - one nicely formatted row showing the group in one column and all of the group members in the other column - both DIRECT and NESTED.

cnmember_namemember_type

Remote Desktop Users

 

 

 

Finance
Sales
Fred
Sam
Joe
Ted

DIRECT
DIRECT
NESTED
NESTED
NESTED
NESTED

 

My guess is that both SEARCH and WHERE are operating on the initial LDAPSEARCH operation. The group itself has matching member_type data.  The searches are all working, and nothing fails, so there doesn't appear to be anything illuminating in the debug log.

I imagine I could REGEX the field to delete the unwanted entries from the view, but that seems like an odd workaround since LDAPGROUP is producing member_type data.

I'm still just shy of having this work.

0 Karma

richgalloway
SplunkTrust
SplunkTrust

That table should have been in the OP since it clarifies the problem.  It appears that ldapgroup creates multivalue fields that standard where/search operators can't handle.  The solution is to expand the multivalue fields before filtering them.  To retain the relationship between member_name and member_type, we'll use mvzip to pair them up before expanding them.

| ldapsearch search="(&(objectClass=Group)(cn=Remote Desktop Users)"
| table cn,distinguishedName
| ldapgroup
``` Combine member_name and member_type
| eval member_name_type=mvzip(member_name, member_type, "#")
``` Put each member into a separate event ```
| mvexpand member_name_type
``` Break the member field apart again ```
| eval member_name_type = split(member_name_type, "#")
| eval member_name=mvindex(member_name_type,0), member_type=mvindex(member_name_type,1)
| where member_type="DIRECT"
| table cn,member_name,member_type

 

---
If this reply helps you, Karma would be appreciated.

ddetlef
Explorer

Thank you very much for the coaching on the multivalue functions.  I had never used any of those before.

Your code suggestions for mvzip/mvexpand/mvindex worked exactly as described.

This solution has the advantage of being able to generalize to many other scenarios.

 

ddetlef
Explorer

It turns out that there is a different, but closely related technique for getting to the same result, if all you are interested in is the narrow goal of listing AD group direct membership.

Instead of using LDAPGROUP, use the LDAPFETCH function.

| ldapsearch search="(&(objectClass=Group)(cn=Remote Desktop Users)"
| mvexpand member
| ldapfetch dn=member attrs="cn"
| table cn

This returns the direct members of the group using their CN or any alternate attribute.

It leaves me wondering what the best cases are for using the LDAPGROUP function.  The official documentation on it is fairly light and I was only able to find a small handful of examples online.

richgalloway
SplunkTrust
SplunkTrust

If your problem is resolved, then please click the "Accept as Solution" button to help future readers.

---
If this reply helps you, Karma would be appreciated.
0 Karma
Get Updates on the Splunk Community!

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...

March Community Office Hours Security Series Uncovered!

Hello Splunk Community! In March, Splunk Community Office Hours spotlighted our fabulous Splunk Threat ...

Stay Connected: Your Guide to April Tech Talks, Office Hours, and Webinars!

Take a look below to explore our upcoming Community Office Hours, Tech Talks, and Webinars in April. This post ...