# Kibana 8.7.1 - Elasticsearch 8.8.2 - LDAPS not initializing

**URL:** <https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453>\
**Category:** Search Guard\
**Created:** [July 13, 2023, 8:18pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453 "2023-07-13T20:18:17Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![novaksam](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/novaksam/32/715_2.png) [@novaksam](https://forum.search-guard.com/u/novaksam)\
**Post date:** [July 13, 2023, 8:18pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/1 "2023-07-13T20:18:17Z")

</div>

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

```auto
_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

```auto
---
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"

```

---

<div class="post-metadata">

**Author:** ![pablo](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/pablo/32/1443_2.png) [@pablo](https://forum.search-guard.com/u/pablo)\
**Post date:** [July 14, 2023, 1:52pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/2 "2023-07-14T13:52:09Z")

</div>

@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?

---

<div class="post-metadata">

**Author:** ![novaksam](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/novaksam/32/715_2.png) [@novaksam](https://forum.search-guard.com/u/novaksam)\
**Post date:** [July 17, 2023, 12:53pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/3 "2023-07-17T12:53:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pablo](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/pablo/32/1443_2.png) [@pablo](https://forum.search-guard.com/u/pablo)\
**Post date:** [July 17, 2023, 2:03pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/4 "2023-07-17T14:03:35Z")

</div>

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

> **[Quick Start](https://docs.search-guard.com/latest/sg-classic-config-migration-quick)**
>
> How to migrate older Search Guard authentication configurations to sg\_authc.yml and sg\_frontend\_authc.yml

---

<div class="post-metadata">

**Author:** ![novaksam](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/novaksam/32/715_2.png) [@novaksam](https://forum.search-guard.com/u/novaksam)\
**Post date:** [July 17, 2023, 2:39pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/5 "2023-07-17T14:39:45Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![novaksam](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/novaksam/32/715_2.png) [@novaksam](https://forum.search-guard.com/u/novaksam)\
**Post date:** [July 17, 2023, 7:16pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/6 "2023-07-17T19:16:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pablo](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/pablo/32/1443_2.png) [@pablo](https://forum.search-guard.com/u/pablo)\
**Post date:** [July 21, 2023, 12:52pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/7 "2023-07-21T12:52:50Z")

</div>

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

> **[Latest Releases](https://docs.search-guard.com/latest/search-guard-versions)**
>
> A list of the current Search Guard releases for all Elasticsearch 7 and Kibana 7 versions.

---

<div class="post-metadata">

**Author:** ![novaksam](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/novaksam/32/715_2.png) [@novaksam](https://forum.search-guard.com/u/novaksam)\
**Post date:** [July 26, 2023, 6:17pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/8 "2023-07-26T18:17:08Z")

</div>

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](https://maven.search-guard.com/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](https://maven.search-guard.com/search-guard-flx-release/com/floragunn/search-guard-flx-elasticsearch-plugin/1.2.0-es-8.8.2/))

---

<div class="post-metadata">

**Author:** ![nils](https://avatars.discourse-cdn.com/v4/letter/n/d6d6ee/32.png) [@nils](https://forum.search-guard.com/u/nils)\
**Post date:** [August 1, 2023, 7:00pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/9 "2023-08-01T19:00:45Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![system](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/system/32/1870_2.png) [@system](https://forum.search-guard.com/u/system)\
**Post date:** [August 22, 2023, 7:00pm UTC](https://forum.search-guard.com/t/kibana-8-7-1-elasticsearch-8-8-2-ldaps-not-initializing/2453/10 "2023-08-22T19:00:48Z")

</div>

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