I'm trying to get the Splunk Support for Active Directory (SA-LDAPsearch) to work with our Active Directory installation, I'm running into a brick wall with the use of STARTTLS and getting this add-on to trust the certificate chain - there seems to be some difference between the documentation for this add-on and changes to Splunk 6.5. It's not clear what needs to go in what stanza for the $SPLUNK_HOME/etc/apps/SA-ldapsearch/local directory, and in which file.
It was a real pain getting the LDAP server certificate for STARTTLS in the first place (had to resort to wireshark), but now that I have the PEM for that, and I can get the entire certificate chain/intermediates, where do they actually go? $SPLUNK_HOME/etc/auth, and then a pointer to a file in the SA-ldapsearch/local/ssl.conf somewhere, or the server.conf?
I've tried putting this in the ssl.conf for the add-on:
[sslConfig] sslRootCAPath = /opt/splunk/etc/auth/ldap.pem sslVerifyServerCert = false
However that doesn't seem to work - note that the documentation points to a different attribute than the Splunk 6.5.x documentation says works.
When I run ldapsearch from OpenLDAP on the command line, I specify a "-Z" which gets authentication to work, however, this also generates an error - additional info: TLS: hostname does not match CN in peer certificate. Using -ZZ will break ldapsearch (CLI) entirely due to this -- I'm hoping that by not verifying the server certificate in the SA that I can get around this issue..
Anyway, does anyone know what the current / accurate / right way is to get this add-on to deal with the STARTTLS within the LDAP(S) and PEM files, paths, etc?
Coming fast and furious with the updates to this question - sorry. I may have made a bit more progress, but, am starting to wonder if the issue is that this SA can't support STARTTLS and only supports TLS/SSL on the TCP connection to the LDAP server itself. Current error is:
ldapserver.domain.com: Could not access the directory service at ldaps://ldapserver.domain.com:389: socket ssl wrapping error: [Errno 104] Connection reset by peer
Our Active Directory server is running LDAP on 389, but requires STARTTLS (which is what is working with command-line ldapsearch)...
If you stare at a problem long enough, you can magically solve it.
I've "hacked" a solution which works for me, and I hope it helps others. I had to edit the ./bin/packages/ldap3/core/connection.py in the SA-ldapsearch to add:
This made sure that the STARTTLS was running. Adding this to ldap3.Connection in bin/packages/app/connection_pool.py, didn't seem to cut it. Indeed, that resulted in:
2017-02-18 12:40:11,539, Level=ERROR, Pid=31089, File=search_command.py, Line=282, Abnormal exit: Failed to retrieve schema information from the directory system agent at ldap://ldapserver.domain.com:389 - cleartext
There was one other change that was required for me to get this to work, and that WAS by editing the connectionpool.py to have:
raiseexceptions=False, in ldap3.Connection. The default here was True.
If I don't do that, then I get:
2017-02-18 12:05:54,664, Level=ERROR, Pid=15576, File=search_command.py, Line=282, Abnormal exit: LDAPNoSuchObjectResult - 32 - noSuchObject - CN=Schema,CN=Configuration,DC=stuff,DC=ldapserver,DC=domain,DC=com - 0000208D: NameErr: DSID-0315270B, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Schema,CN=Configuration,DC=stuff,DC=ldapserver,DC=domain,DC=com' - searchResDone - None
Not sure what's triggering that, but, indeed, that sort of schema check fails, and I haven't figured out what may need to be modified to make this error go away without disabling the raise_exceptions default.
Happy to hear of other/better solutions to this, but, this got me going again.
I am stuck here too.. Let me know if this works for you