-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Python LDAP Technology Add-On for Splunk
This app provides a generating command to directly query an LDAP directory from Splunk search without any dependencies or configuration. Simply install this app on your search head then use the ldapquery command like so: | ldapquery uri="ldap://ldap.example.com" basedn="dc=example,dc=com"
Please see below for more information regarding usage options and known issues.
N.B. This app uses the splunk-sdk-python-1.6.2 and python-ldap libraries.
- Release notes
- Support and resources
- Requirements
- Installation
- Configuration
Version 0.2.* of TA-pyLDAP is compatible with:
| Splunk Enterprise versions | 6.3+ |
|---|---|
| Platforms | Linux |
| Lookup file changes | None |
- None
- On older distributions which lack Python2.7 (such as RHEL 6), the libpython2.7.so.1.0 dependency is not met by the app (https://github.com/doksu/TA-pyLDAP/issues/1)
- STARTTLS support not yet implemented (use ldaps for the time being)
- Unauthenticated binds to Active Directory currently fail (other LDAP implementations work well)
Please post questions at https://answers.splunk.com, however this app is provided as is with no warranty, implied or otherwise; please see the LICENSE document for more information. Feedback about possible improvements and good news stories of how this app has helped your organisation are most welcome.
- None
To function properly, TA-pyLDAP requires the following software:
- Linux
- Splunk Enterprise 6.3+
Simply install this app on your search head/s and restart Splunk.
No configuration is required. For your convenience, if you wish to use the same arguments in multiple ldapquery-based searches, we suggest using a macro.
Here's a complex example utilising all the ldapquery command's optional arguments:
| ldapquery uri="ldaps://ldap.example.com:636" verifycert=true scope=onelevel basedn="ou=users,dc=example,dc=com" binddn="dn=splunk,ou=serviceaccounts,dc=example,dc=com" bindpassword="password" ldapfilter="(objectClass=posixAccount)" attributelist="cn mail"
The reader may be wondering why this command has been implemented to use passwords in plain text. In organisations where unauthenticated binds are not permitted, service accounts are used and they always have far greater restrictions placed upon them than an ordinary user, especially the users who would typically have access to resources where the search string would be visible (such as the _audit index where searches are logged) and so it stands to reason that implementing arguably trivially-reversible encryption of credentials on the search head in this context is of no gain. This is not just theoretical, it's actually been done: http://maratto.blogspot.com/2016/03/reverse-engineering-splunk-password.html