Kibana 8.7.1 - Elasticsearch 8.8.2 - LDAPS not initializing

If you think it is a bug report or you have a technical issue, please answer the following questions. For general questions, you can delete these questions.

Elasticsearch version: 8.8.2

Server OS version: Rocky Linux 9.2

Kibana version (if relevant): 8.7.1

Browser version (if relevant): Firefox 114.0.2

Browser OS version (if relevant): Win 10

Describe the issue: After upgrading from 7.11.9 cluster to 8.8.2 I’m having issues using LDAP for Kibana authentication, and presumably other components too. The packet captures against the configured LDAP server appear to show that Searchguard is attempting to do cleartext LDAP binds over the LDAPS port, and it doesn’t appear to support LDAP signing. If there are

Steps to reproduce:
1.
2.
3.

Expected behavior:

Provide configuration:
elasticsearch/config/elasticsearch.yml
elasticsearch/plugins/search-guard-7/sgconfig/sg_config.yml
kibana/config/kibana.yml (if relevant)

Provide logs:
Elasticsearch
Kibana (if relevant)

Screenshots (if relevant):

Errors in browser console (if relevant):

Additional data:

sg_config.yml - sanitized

_sg_meta:
  type: "config"
  config_version: 2
sg_config:
  dynamic:
    filtered_alias_mode: "warn"
    disable_rest_auth: false
    disable_intertransport_auth: false
    respect_request_indices_options: false
    kibana:
      multitenancy_enabled: true
      server_username: "kibanaserver"
      index: ".kibana"
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: "192\\.168\\.0\\.10|192\\.168\\.0\\.11"
        remoteIpHeader: "x-forwarded-for"
    authc:
      jwt_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          challenge: false
          type: "jwt"
          config:
            jwt_header: "Authorization"
            roles_key: null
            signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key"
            subject_key: null
            jwt_url_parameter: null
        authentication_backend:
          type: "noop"
          config: {}
        description: "Migrated from v6"
      ldap:
        http_enabled: true
        transport_enabled: false
        order: 5
        http_authenticator:
          challenge: true
          type: "basic"
          config: {}
        authentication_backend:
          type: "ldap"
          config:
            bind_dn: "cn=ELK,ou=users,dc=my,dc=com"
            verify_hostnames: "true"
            password: "[REMOVED]"
            usersearch: "(userPrincipalName={0})"
            enable_ssl_client_auth: "false"
            hosts:
            - "ldap.my.com:636"
            username_attribute: "userPrincipalName"
            userbase: "ou=users,dc=my,dc=com"
            enable_start_tls: "false"
            enable_ssl: "true"
            trust_all: "true"
        description: "Migrated from v6"
      basic_internal_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 4
        http_authenticator:
          challenge: true
          type: "basic"
          config: {}
        authentication_backend:
          type: "intern"
          config: {}
        description: "Migrated from v6"
      proxy_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 3
        http_authenticator:
          challenge: false
          type: "proxy"
          config:
            roles_header: "x-proxy-roles"
            user_header: "x-proxy-user"
        authentication_backend:
          type: "noop"
          config: {}
        description: "Migrated from v6"
      clientcert_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 2
        http_authenticator:
          challenge: false
          type: "clientcert"
          config:
            username_attribute: "cn"
        authentication_backend:
          type: "noop"
          config: {}
        description: "Migrated from v6"
      kerberos_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 6
        http_authenticator:
          challenge: true
          type: "kerberos"
          config:
            strip_realm_from_principal: "true"
            krb_debug: "false"
        authentication_backend:
          type: "noop"
          config: {}
        description: "Migrated from v6"
    authz:
      roles_from_another_ldap:
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          type: "ldap"
          config: {}
        description: "Migrated from v6"
      ldap:
        http_enabled: true
        transport_enabled: false
        authorization_backend:
          type: "ldap"
          config:
            verify_hostnames: "true"
            hosts:
            - "ldap.my.com:636"
            bind_dn: "cn=ELK,ou=users,dc=my,dc=com"
            password: "[REMOVED]"
            userbase: "ou=users,dc=my,dc=com"
            usersearch: "(sAMAccountName={0})"
            username_attribute: "DistinguishedName"
            rolebase: "ou=groups,dc=my,dc=com"
            rolesearch: "(member={0})"
            rolename: "cn"
            enable_start_tls: "false"
            enable_ssl: "true"
            trust_all: "true"
            enable_ssl_client_auth: "false"
            resolve_nested_roles: "false"
            skip_users:
            - "kibanaserver"
            - "beats"
            - "elastalert"
            - "es-curator"
            - "logstash"
            - "monitoring"
            - "admin"
        description: "Migrated from v6"
    auth_failure_listeners: {}
    do_not_fail_on_forbidden: true
    multi_rolespan_enabled: false
    hosts_resolver_mode: "ip-only"
    transport_userrname_attribute: null
    do_not_fail_on_forbidden_empty: false

sg_authc.yml - sanitized

---
auth_domains:
- type: "basic/internal_users_db"
  skip:
    users: "*@my.com"
- type: "basic/ldap"
  ldap:
    idp:
      hosts:
      - "ldap://ldap.my.com"
      bind_dn: "cn=ELK,ou=users,dc=my,dc=com"
      password: "[REMOVED]"
    user_search:
      base_dn: "ou=users,dc=my,dc=com"
      filter:
        raw: "(userPrincipalName=${user.name})"
  additional_user_information:
  - type: "ldap"
    ldap:
      idp:
        hosts:
        - "ldap://ldap.my.com"
        bind_dn: "cn=ELK,ou=users,dc=my,dc=com"
        password: "[REMOVED]"
      user_search:
        base_dn: "ou=users,dc=my,dc=com"
        filter:
          raw: "(sAMAccountName=${user.name})"
      group_search:
        base_dn: "ou=groups,dc=my,dc=com"
        filter:
          raw: "(member=${dn})"
        role_name_attribute: "cn"
  user_mapping:
    user_name:
      from_backend: "$.ldap_user_entry.userPrincipalName"

@novaksam Just to clarify. The shared sg_config.yml is the config from 7.11.9 and sg_authc.yml is the one you use in FLX. Is that correct?
What is the FLX plugin version?

I’m on FLX 1.2.0, both files were generated during config backup, and the new post prompt asked to upload sg_config.yml, though I was reasonably certain sg_authc.yml is where I needed to look.

@novaksam Did you follow the migration procedure described in SG documentation?

Yup, did that last fall when I was still running version 7.

I was able to get it working by bringing the 'additional_user_information" section up into the main LDAP section, along with some other changes. I don’t know why sgctl is still pulling down the legacy sg_config; is that normal behavior post upgrade? Additionally, the SAML authentication section doesn’t really spell out how to assign roles from SAML responses; obviously it says ‘specify a name’ but it doesn’t really lay out how things like multiple roles in the same SAML response are handled and I’m not finding an obvious way to turn on TRACE/DEBUG logging to troubleshoot it on my own.

I can start another thread on that topic if you prefer.

@novaksam Just a quick question regarding your previous and current ELK versions.
You’ve reported version 7.11.9. Is that correct? According to Elasticsearch, the highest patch version of 7.11 is 7.11.2. Please confirm.

Also, according to your initial post, your Elasticsearch version is 8.8.2 and Kibana 8.7.1.
If that is correct, you are using an unsupported version of Elasticsearch.

I upgraded from 7.17.9 to 8.8.2 (Elasticsearch)/8.7.1 (Kibana). My bad on the old version.

There is a Kibana plugin for 8.7.1 (Index of search-guard-flx-release/com/floragunn/search-guard-flx-kibana-plugin/1.2.0-es-8.7.1) and 8.8.2 for elasticsearch (Index of search-guard-flx-release/com/floragunn/search-guard-flx-elasticsearch-plugin/1.2.0-es-8.8.2)

Try to change the URL specified for hosts from ldap://ldap.my.com to ldaps://ldap.my.com. That should activate TLS.

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