Splunk Support for Active Directory: Is it possible to pass a variable in to ldapsearch?

[IngloriousSplun]

I have a requirement to display an LDAP user's common name and department within a table that also displays their login statistics for Splunk. My original thought process was to use a subsearch where I collected the user login info, and then have a main search, in this case using ldapsearch, where I would pass the users to determine their CN and Department. It seems as though I can't actually pass in a variable to ldapsearch, or I'm getting an unexpected result that it doesn't like because I get empty results. The search string I'm using is the following:

| ldapsearch domain=DOMAIN search="(samAccountName=$user$)" attrs="cn,department" | append [search info login source=audittrail user=* (action="login attempt" AND info="succeeded" AND host="SEARCH-HEAD" AND user!="admin")] | stats count(action) AS "Total Logins", values(cn) AS "Full Name", values(department) AS "Organization" | sort -"Total Logins"

If I replace the $user$ with an actual username, the above works. I've also tried using ldapfilter, which works, however, it reports an error that states

[Indexer-Peer-A] External search command 'ldapfilter' returned error code 1. Script output = " ERROR The default configuration stanza for ldap.conf is missing.

I have tried installing the SA-ldapsearch add-on to the indexers and configuring ldap.conf, and I've also tried adding in the "host" and "port" attributes in the normal openldap ldap.conf file. I can't get that error to disappear. Despite that, using ldapfilter works perfect and returns the results I expect. I would use this method provided I can get the errors to go away.

Thoughts?

Thanks.

[IngloriousSplun · Accepted solution]

I managed to resolve the error with ldapfilter using the following search: info login source=audittrail user=* (action="login attempt" AND info="succeeded" AND host=SEARCH_HEAD AND user~="admin") | eval ID=user | table ID, cn, department | ldapfilter domain=default search="(samAccountName=$ID$)" attrs="cn, department".

[MartinMcNutt]

That is awesome.... I do have a ticket open with Splunk to figure out why sa-ldapsearch is doing that.

Just remember if you plan on putting that into a dashboard, you may have to hide the LDAP part in a macro to avoid Splunk thinking it is a dashboard token. That one caught me by surprise. Doing dashboards / reports is not my full time job. 🙂

[MartinMcNutt]

I am curious if it is the same issue I encountered. Try this...

Put in and eval statement after your user search | eval ID=user

change samaccount to look at the new field.

(samAccountName=$ID$)

I suspect that the token is not getting properly passed to the pipeline because of some data issues.

EDIT
It looks like |eval ID= was a red herring. I worked my search and simple added | table user prior to the | ldapfilter and things work ok.

I am going to open up a ticket now and maybe I can't have it solved before summer gets here.

[IngloriousSplun]

Thanks for the update, I managed to resolve the error with ldapfilter using the following search: info login source=audittrail user=* (action="login attempt" AND info="succeeded" AND host=SEARCH_HEAD AND user~="admin") | eval ID=user | table ID, cn, department | ldapfilter domain=default search="(samAccountName=$ID$)" attrs="cn, department"

Thanks for that tip!