security: [BUG] LDAP fails when the `security.ssl.transport.truststore_filepath` is missing

What is the bug? This is a continuation of the issue 1866. The LDAP authentication process fails when the security.ssl.transport.truststore_filepath is missing from the opensearch.yml file, leading to an unresolved bug from a previous issue. The steps to reproduce the bug are documented in the Opensearch forum thread, along with the host/environment details.

How can one reproduce the bug? Steps to reproduce the behavior:

All the steps and config files are published in https://forum.opensearch.org/t/empty-file-path-for-plugins-security-ssl-transport-truststore-filepath-ldap-authentication/12991 thread.

What is the expected behavior? The LDAP authentication process should function as expected when the security.ssl.transport.truststore_filepath is missing from the opensearch.yml file, and the pemtrustedcas_filepath: is included in the config.yml file

What is your host/environment? All the information is provided in the Opesearch forum thread

Do you have any screenshots? If applicable, add screenshots to help explain your problem.

Do you have any additional context? It appears that the Java code responsible for the logic of how the CA certificates are read is located at this location. We are unsure if the documentation is incorrect, as the security.ssl.transport.truststore_filepath option is listed as optional, while it appears to be required for authorization. We are also considering the possibility of changing the logic for searching the IdP RootCA certificate

About this issue

Original URL
State: closed
Created a year ago
Reactions: 1
Comments: 18 (6 by maintainers)

Most upvoted comments

Does exist any way to counturn this problem?

pabloalcantara on Jun 7, 2023

Thank you @vaskosmihaylov. I opened a PR on the documentation website to address this in documentation: https://github.com/opensearch-project/documentation-website/pull/5727

cwperks on Dec 1, 2023

@vaskosmihaylov I just tried to reproduce this error. I was able to reproduce the error from the OP description by setting enable_ssl: true and not configuring pemtrustedcas_filepath on the LDAP config, but after some trial and error I was able to get it to work.

One thing I noticed is that on this forum post, the pemtrustedcas_filepath was only configured in the ldap authenticator (authc: section) and was not also configured in the ldap authorizer (authz: section). After configuring this setting twice (in both authc: and authz:) I was able to login.

From my understanding of the authz portion of the config is that is queries the LDAP directory after authentication is successful to extract information about the user’s roles from the LDAP directory.

authc:
  ldap_auth:
    order: 1
    description: "Authenticate using LDAP"
    http_enabled: true
    transport_enabled: false
    http_authenticator:
      type: basic
      challenge: false
    authentication_backend:
      type: ldap
      config:
        pemtrustedcas_filepath: /usr/share/opensearch/config/root-ca.pem
        enable_ssl: true
        enable_start_tls: false
        enable_ssl_client_auth: false
        verify_hostnames: false
        hosts:
        - openldap:636
        bind_dn: cn=readonly,dc=example,dc=org
        password: changethistoo
        userbase: ou=People,dc=example,dc=org
        usersearch: (cn={0})
        username_attribute: cn

authz:
  ldap_roles:
    description: "Authorize using LDAP"
    http_enabled: true
    transport_enabled: false
    authorization_backend:
      type: ldap
      config:
        pemtrustedcas_filepath: /usr/share/opensearch/config/root-ca.pem <- Must configure here as well
        enable_ssl: true
        enable_start_tls: false
        enable_ssl_client_auth: false
        verify_hostnames: true
        hosts:
        - openldap:636
        bind_dn: cn=readonly,dc=example,dc=org
        password: changethistoo
        userbase: ou=People,dc=example,dc=org
        usersearch: (cn={0})
        username_attribute: cn
        skip_users:
          - admin
          - kibanaserver
        rolebase: ou=Groups,dc=example,dc=org
        rolesearch: (uniqueMember={0})
        userroleattribute: null
        userrolename: disabled
        rolename: cn
        resolve_nested_roles: false

cwperks on Nov 21, 2023

[Triage] Thanks for filing @vaskosmihaylov looks like have an issue here that should be investigated. Additionally thanks for following up on the forums and back here.

peternied on Mar 13, 2023