Subsearch assistance - feel like I'm close

[erinmichaud]

I have ldap logs that give me events that look like this:

Feb 21 13:13:22 ldap.foo.com slapd[28026]: conn=15306 fd=108 ACCEPT from IP=123.4.5.67:48504 (IP=0.0.0.0:636)
Feb 21 13:13:22 ldap.foo.com slapd[28026]: conn=15306 op=0 BIND dn="" method=128
Feb 21 13:13:22 ldap.foo.com slapd[28026]: conn=15306 op=0 RESULT tag=97 err=0 text=
Feb 21 13:13:22 ldap.foo.com slapd[28026]: conn=15306 op=1 SRCH base="dc=bar,dc=foo,dc=com" scope=0 deref=0 filter="(objectClass=*)"
Feb 21 13:13:22 ldap.foo.com slapd[28026]: conn=15306 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Feb 21 13:13:22 ldap.foo.com slapd[28026]: conn=15306 op=2 UNBIND

I've been using subsearch functionality to get the "conn" value for each BIND attempt with an empty dn, and then use those conn values to show me the the IP (123.4.5.67 in the ACCEPT line above) where that bind came from.

This is an attempt that doesn't quite work
host=ldap.foo.com sourcetype=openldap:access ACCESS [search host=ldap.foo.com" sourcetype=openldap:access "BIND dn=\"\"" |table conn |dedup conn |format ]

the subsearch, run alone, returns exactly what I want, lets say 100 events of an empty bind dn for my chosen timeframe. However, when I then use that to feed the main search, where I believe I'm asking "find an event with those same conn values, but with the word ACCEPT in it" - then it brings me back ALL the events with ACCEPT (lets say 300 events), including those with a non-empty dn bind. I feel I'm missing something simple, but I'm at a loss and have sliced and diced several ways without joy.

A nudge in the right direction would be most welcome.

[to4kawa]

host="ldap.foo.com"  sourcetype=openldap:access ACCEPT OR (BIND "dn=\"\"") 
| stats count by conn
| where count > 1

Hi, @erinmichaud
if you want only conn, try this.

[manjunathmeti · Accepted solution]

Since you have a common field and value (conn=15306) pair in each event, you don't need to run the search again. Use stats to merge events based on common field.

host=ldap.foo.com sourcetype=openldap:access ACCESS OR "BIND dn=\"\"" | stats first(*) as * by conn | table conn, IP, fd, op, method

From your sample logs Splunk sets IP value to 0.0.0.0:636 by default, If you want IP=123.4.5.67 then extract it before using stats:

host=ldap.foo.com sourcetype=openldap:access ACCESS OR "BIND dn=\"\"" | rex "IP=(?<IP>\d+.\d+.\d+.\d+):" | stats first(*) as * by conn | table conn, IP, fd, op, method

[erinmichaud]

Thanks for this - it's close but no cigar, as the OR is giving me all the conn values, not just the ones with empty bind DN (same as the subsearch technique is doing) but this is far more elegant and is getting me closer to what I need, so I'll keep working from this point. Thanks to both - I'll be sure to post when I get it. Appreciate the help!

[drodman29]

Add a count and a | where count>1 - assuming your Conn values are not reused.

[teekayx]

+1 for this. This is more efficient than the subsearch.

[erinmichaud]

Event search shows that its searching for a total of 428 (for my fixed date/time range) conn values like so (this is snipped for brevity):

 search host="ldap.foo.com"  sourcetype=openldap:access ACCEPT ( ( conn="16232" ) OR ( conn="17955" ) OR ( conn="17954" ) OR ( conn="16231" ) OR ( conn="16230" ) OR ( conn="16226" ) OR ( conn="16224" ) OR ( conn="17949" ) OR ( conn="17943" ) OR ( conn="16178" ) OR ( conn="17868" ) OR ( conn="17867" ) OR ( conn="16177" ) OR ( conn="17674" ) OR  ( conn="15099" ) )

But what the main search returns is results from more than 600 different connection values for the same time period (eg. more than what the subsearch returns, containing connections I am not interested in)

[erinmichaud]

This DOES work - I was getting mislead by my data. Turns out the conn value does get re-used, so as soon as I expanded my timerange beyond (whatever value - it varies depending on activity) I was getting seemingly bogus hits for this. Thanks for the assistance on this

[teekayx]

The subsearch works fine in my test. Is that the exact query you're using? Is it a typo you're using ACCESS instead of ACCEPT?

[erinmichaud]

yes - ACCESS/ACCEPT is typo on my part as I wrote this. Looking for ACCEPT in the main search gives me all ACCEPT lines, not just ones from the conn values returned in my subsearch

[teekayx]

can you check under Inspect Job > search job properties > eventSearch and see what query are you getting?
I got search host=ldap.foo.com sourcetype=openldap:access ACCEPT ( ( conn="15306" ) ) based on the sample data you provided