LDAP Integration Not Working

Elastic Stack Elasticsearch
1

We're running inhouse platinum version of ELK stack 7.16. We've tried to use AD for user authentication, but it is not working and ends throwing invalid credential error. We're 100% sure that it is valid password.

This is the ES config:

xpack:
    security:
        authc:
            realms:
                native:
                    native1:
                        order: 0
                ldap:
                    ldap1:
                        order: 1
                        url: "ldaps://xxxxxxxxx:636"
                        ssl:
                            certificate_authorities: ["/etc/elasticsearch/certs/xxxxx.cer","/etc/elasticsearch/certs/xxxxx.cer","/etc/elasticsearch/certs/xxxxx.cer"]
                        bind_dn: "cn=xxx.xx@mgt.bps,OU=Users,OU=RBAC,OU=BPS,DC=mgt,DC=bps"
                        user_search:
                            base_dn: "OU=Users,OU=RBAC,OU=BPS,DC=mgt,DC=bps"
                            filter: "(cn={0})"
                        group_search:
                            base_dn: "OU=Tasks,OU=RBAC,OU=BPS,DC=mgt,DC=bps"
                            filter: "objectClass=group"
                        files:
                            role_mapping: "/etc/elasticsearch/role_mapping.yml"
                        unmapped_groups_as_roles: false```

This is the exception I'm getting

[2023-07-19T11:55:56,779][WARN ][o.e.x.s.a.l.s.LdapUtils  ] [xxxxx] Failed to obtain LDAP connection from pool - LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839', ldapSDKVersion=4.0.8, revision=28812)
[2023-07-19T11:55:56,783][DEBUG][o.e.x.s.a.l.LdapRealm    ] [xxxxx] Exception occurred during authenticate for ldap/ldap1
com.unboundid.ldap.sdk.LDAPBindException: 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839
        at com.unboundid.ldap.sdk.LDAPConnectionPool.createConnection(LDAPConnectionPool.java:1372) ~[unboundid-ldapsdk-4.0.8.jar:4.0.8]
        at com.unboundid.ldap.sdk.LDAPConnectionPool.createConnection(LDAPConnectionPool.java:1258) ~[unboundid-ldapsdk-4.0.8.jar:4.0.8]
        at com.unboundid.ldap.sdk.LDAPConnectionPool.getConnection(LDAPConnectionPool.java:1792) ~[unboundid-ldapsdk-4.0.8.jar:4.0.8]
        at java.security.AccessController.doPrivileged(AccessController.java:569) ~[?:?]
        at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.privilegedConnect(LdapUtils.java:76) ~[x-pack-security-7.17.6.jar:7.17.6]
        at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.searchForEntry(LdapUtils.java:296) [x-pack-security-7.17.6.jar:7.17.6]
        at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.searchForEntry(LdapUtils.java:231) [x-pack-security-7.17.6.jar:7.17.6]
        at org.elasticsearch.xpack.security.authc.ldap.LdapUserSearchSessionFactory.findUser(LdapUserSearchSessionFactory.java:271) [x-pack-security-7.17.6.jar:7.17.6]
        at org.elasticsearch.xpack.security.authc.ldap.LdapUserSearchSessionFactory.getSessionWithPool(LdapUserSearchSessionFactory.java:84) [x-pack-security-7.17.6.jar:7.17.6]
        at org.elasticsearch.xpack.security.authc.ldap.PoolingSessionFactory.session(PoolingSessionFactory.java:108) [x-pack-security-7.17.6.jar:7.17.6]
        at org.elasticsearch.xpack.security.authc.ldap.LdapRealm.lambda$doAuthenticate$1(LdapRealm.java:147) [x-pack-security-7.17.6.jar:7.17.6]
        at org.elasticsearch.xpack.security.authc.ldap.LdapRealm$CancellableLdapRunnable.doRun(LdapRealm.java:343) [x-pack-security-7.17.6.jar:7.17.6]
        at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:777) [elasticsearch-7.17.6.jar:7.17.6]
        at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:26) [elasticsearch-7.17.6.jar:7.17.6]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
        at java.lang.Thread.run(Thread.java:833) [?:?]
[2023-07-19T11:55:56,785][WARN ][o.e.x.s.a.RealmsAuthenticator] [xxxxx] Authentication to realm ldap1 failed - authenticate failed (Caused by LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839', ldapSDKVersion=4.0.8, revision=28812))
2

As you have a platinum license, I'd suggest to contact the support team.

3

As we need to contact multiple hops (as we don't have the support details with our team), I think this would be the faster approach, so would help me in this case.

4

Any help on the next steps, leads would be highly appreciated.

Thank you

5

Try to check your LDAP bind DN user password. Based on the exception stacktrace, I think Elasticsearch is unable to bind using your bind user.

6

This is definitely the case here.

Elasticsearch is trying to establish a connection using this user:

  bind_dn: "cn=xxx.xx@mgt.bps,OU=Users,OU=RBAC,OU=BPS,DC=mgt,DC=bps"

The directory (AD) is reporting a credentials error when Elasticsearch tries to authenticate using that bind_dn, and the secure_bind_password from the node's keystore

My best suggestion for debugging would be to

  • Access a shell/terminal on the host for the where the error is being logged
  • Copy the bind_dn from the elasticsearch.yml
  • Copy the secure_bind_password from the keystore (use the command elasticsearch-keystore show xpack.security.authc.realms.ldap.ldap1.secure_bind_password)
  • Using that bind_dn and secure_bind_password, use a CLI ldap tooling such as ldapwhoami or ldapsearch to verify that you can connect to the directory.

If you can't connect (using the configured DN/password) from a shell, then it's definitely not an Elasticsearch issue, and you'll need to try and diagnose it with your internal teams (AD/security).

Separately, you've said this is AD, but you're using a generic ldap realm instead of the AD specific realm - is that intentional? It's recommended that you use the AD realm when connecting to active directory servers.

7

Thanks for you suggestions, I will check and update here.

8

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