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.
... View more