Splunk Support for Active Directory: How to configure the add-on to use STARTTLS as the certificate?

[howyagoin]

Hi,

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)...

[Amandeepsin]

I am stuck here too.. Let me know if this works for you

[howyagoin · Accepted solution]

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:

auto_bind=AUTO_BIND_TLS_BEFORE_BIND,

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 connection_pool.py to have:
raise_exceptions=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.