I am at the very end of installing the Splunk App for Windows Infrastructure and everything is working great except the LDAP Search feature of the Splunk Supporting Add-on for Active Directory (SSAOAD...or SAD for short) 🙂 . Everything else seems to be functioning properly, but the LDAP functions support a large number of dashboards so we can't 'go live' yet.
An example of one not working would be the all users macro query:
ldapsearch domain="$domain$" search="(&(objectclass=user)(!(objectClass=computer)))"|sort sAMAccountName|table sAMAccountName,cn,userPrincipalName,userAccountControl
Or any other macro that has ldapsearch in it works until the point in the pipeline where ldapsearch is introduced. When I go to the "SAD" configuration page and do a test on my domain, the test connection passes. I have rebuilt the LDAP lookup and backed it out to the top level and it passes again. I have run the
|ldaptestconnection domain=mydomainname and it populates with the expected single event signifying success.
When I run the
|ldapsearch command directly from SAD on the search head, I get the following:
Script output = " ERROR Missing required value for alternatedomain in ldap/default. "
I'm guessing it means ldap.conf. Oddly there is a local directory, which I don't believe should require a default directory but it's looking there anyways. Everything is #'d out. Against my better judgement, I added the contents to from the LOCAL ldap.conf at the top of and restarted Splunk services on the search head and things are still not populating.
What am I missing?
To work around this issue until the app is updated, it works if you update @Configuration( ) to @Configuration(local=True) in ldapsearch.py, ldapfetch.py, ldapfilter.py, ldapgroup.py, and ldaptestconnection.py.
If there were pre-existing settings in the parenthesis in @Connection( ), you can keep the pre-existing settings and add local=True - such as @Connection(local=True, retainsevents=True)
The app now has a workaround for this in the form of a conf file:
We had same issue when we updated for 1.x to 2.1.0 of SA-LDAP.
It isn't clear in the documentation but the name - default is just a label and you will probably have several labels.
While the UI shows Domain name = default, this is just a label, your domain actually goes in the Alternative domain name.
so: default = blah.blah.blah.us like default = ci.washington.dc.us
This default label is what is used in searches if you do not put in any domain.
Additionally, we have an internal domain name that we put a label of NETBiosName = WashingtonDC
We also learned that it appears to be case sensitive in searching and added the label CAPsNETBiosName = WASHINGTONDC
now when you search for WashingtonDC OR WASHINGTONDC OR ci.washington.dc.us you should get results.
I was looking at this question because we also noticed that the time being returned is not parsing well, so beware of that.
Now you will get times that look like 2015-04-08T16:07:57.041170Z when they had been returning 2015/04/08 01:36:00 PDT.
As krish3 said... but if your ldap.conf is right, let me tell you a little story. At some point, someone decided it would be cool to name the SA-ldapsearch directory configuration file ldap.conf... which has potential to conflict with the core's ldap.conf. I know of two instances where that has caused problems like this, and I don't believe anyone's been able to actually review configurations closely enough to isolate why. Perhaps your support ticket and diag will be the one that tips the balance! Tell 'em TAG-9200 sent you.
Please share your inputs in ldap.conf files...
I believe you are missing to add alternate domain values. Once you provide sample of your ldap.conf i would be able to help further..