Question over TLS transport configs as relates to LDAP authc

Security
,
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):

Describe the issue:Empty file path for plugins.security.ssl.transport.truststore_filepath

Configuration: Active Directory Authc

Relevant Logs or Screenshots:

I have looked at these bug reports and topics:

As I look to address this, I had a few questions about how these certs and functions relate. My system has a machine cert from our MS CA. I created the self signed certs because I was following along the documentation, and also didn’t want to explain tons of stuff to get the additional certs. Perhaps this was a mistake.

However, as it stands the I have the CA cert, the node cert and the admin cert for my single node instance of opensearch, with dashboards on the same server.

It create the recommended configurations:

config.yml → pemtrustedcas_filepath

opensearch.yml → plugins.security.ssl.transport.truststore_filepath

If I configure these with the CA chain for our MS CA, and the machine cert from our MS CA, won’t this screw up the transport between node, dashboards, etc?

Do I need to switch all of the certs to use the MS CA?

3

Hi @subgenius,

You should not need to replace all OpenSearch node/admin certificates with certificates issued by your Microsoft CA solely for LDAP/AD authentication.

There are two separate TLS areas involved:

  1. OpenSearch TLS:
    Transport TLS is used for node-to-node communication.
    HTTP TLS is used for REST/API clients, including OpenSearch Dashboards connecting to OpenSearch.
  2. LDAP/AD TLS:
    This is used by the Security plugin when it connects to the LDAP/AD server.

By default, LDAP certificate validation can use the trust material configured for OpenSearch Security.
If your AD certificate is signed by a different CA, you can either:

  • add the AD CA to the existing trust chain, or
  • configure a dedicated LDAP trust CA using pemtrustedcas_filepath.

Reference and more detail: https://docs.opensearch.org/latest/security/authentication-backends/ldap/#certificate-validation

If you use a dedicated LDAP CA, make sure pemtrustedcas_filepath is configured in every LDAP config block where LDAP is used (for example both authc and authz if applicable).

Also, if you change the LDAP settings in config.yml, make sure the updated Security configuration is actually applied to the Security index, for example via securityadmin.sh or the Security REST API.

If the issue persists, could you share your redacted opensearch.yml and the relevant LDAP part of config.yml?

4

Thanks for the clear explanation! It answered exactly what I was asking. I configured the CA chain in the ldap authc config and promptly got a host validation error. I turned off host validation both in the config and in the jvm and now AD auth works

I have a conversation open with our AD admin about the redirect and where we can list that as a SAN in the cert.
It seems like these redirects may be a known issue with AD?
“Could not follow referral to ldaps://DomainDnsZones.[domain].lan”

“(certificate_unknown) No subject alternative DNS name matching DomainDnsZones.[domain].lan found”

5

Issue is resolved completely. After conferring with our AD admin, he provided several suggestions that don’t involve disabling ldap host verification (both in ldap config and jvm options)

For us at least, replacing the ldap port (636) with port 3269 allows querying the Global Catalog and eliminates the redirect that was causing the error.