Receiving error configuring LDAP Auth

Search Guard
1

TL;DR

Receiving the following error when configuring LDAP authentication:

Empty file path for searchguard.ssl.transport.truststore_filepath

Issue

While configuring LDAP authentication in Search Guard, I’m receiving the following error in the Kibana logs:

{"type": "server", "timestamp": "2020-04-30T17:27:27,005Z", "level": "WARN", "component": "c.f.d.a.l.b.LDAPAuthorizationBackend", "cluster.name": "elk-es", "node.name": "elk-es-coord-1", "message": "Unable to connect to ldapserver ldap.example.com:636 due to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore_filepath]. Try next.", "cluster.uuid": "s2SUJJW_TJS7977zJJGpmQ", "node.id": "d74bPNTVS-2Kc6cm22455w"  }

While While it’s correct that I don’t have searchguard.ssl.transport.truststore_filepath set, my understanding is that I can set the chain of trust in searchguard.ssl.http.pemtrustedcas_filepath, which I do (see elasticsearch.yml).

I’m using Elasticsearch/Kibana 7.6.2, with corresponding Search Guard plugins.

Relevant files are attached.elasticsearch.yml (1.6 KB) kibana.yml (1.5 KB) sg_config.yml (10.8 KB)

2

Yes, this seems strange to me as well, and it may be an issue with how the LDAP module looks up the root CA for certificate validation. If no specific CA is configured, it should fall back to the settings in eslasticsearch.yml, and it should not matter if you use PEM or JKS. We will look into this.

As a workaround, you can also specify a root CA in the configuration settings of the LDAP module, like:

ldap:
  description: "Authenticate via LDAP or Active Directory"
  ...
  http_authenticator:
  ...
  authentication_backend:
    config:
      # enable ldaps
      enable_ssl: true
      # enable start tls, enable_ssl should be false
      enable_start_tls: false
      # send client certificate
      enable_ssl_client_auth: false
      # verify ldap hostname
      verify_hostnames: false
      pemtrustedcas_filepath: /path/to/trusted_cas.pem <--- here
      hosts:
        - ldap.example.com:636
        ...

Could you please try that approach and see if this solves the issue for the moment?

3

I’ll give it a shot. Will this be an absolute filepath, or relative, like in elasticsearch.yml?

4

That appears to have done it. I’m not getting any errors now in the log, and instead of getting:

Invalid username or password, please try again

I’m now getting:

{"statusCode":403,"error":"Forbidden","message":"no permissions for [indices:data/read/search] and User [name=CN=me,OU=users,DC=example,DC=com, backend_roles=[], requestedTenant=null]: [security_exception] no permissions for [indices:data/read/search] and User [name=CN=me,OU=users,DC=example,DC=com, backend_roles=[], requestedTenant=null]"}

which, IIRC, means that I’m authenticating, but there aren’t any roles defined. Just as a note: I also inserted the pemtrustedcas_filepath: ... in authz, as well as authc. My assumption is that authz will need the same. I assume that no errors means I didn’t hurt anything, at the very least.

5

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.