LDAP config problem

Elastic Stack Elasticsearch
1

Hi
I have a problem with LDAP configuration and integration with Acitive directory.
I don;t have any response form elastic when I tried to logon using AD user.
I activate the DBUG trace for LDAP auth but still ELK log is empty.

bellow my config:

xpack.security.enabled: true
xpack.security.audit.enabled: false
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.verification_mode: certificate 
xpack.security.http.ssl.key: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx.key
xpack.security.http.ssl.certificate: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx_certnew.cer
xpack.security.http.ssl.certificate_authorities: /xxxxx/xxxxx/elasticsearch_7.3.0/config/ca.crt
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate 
xpack.security.transport.ssl.key: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx.key
xpack.security.transport.ssl.certificate:/xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx_certnew.cer
xpack.security.transport.ssl.certificate_authorities: /xxxxx/xxxxx/elasticsearch_7.3.0/config/ca.crt 
xpack.security.authc.realms:
    ldap.ldap1:
        order: 0
        url: "ldaps://xxxx.xxxx.xxx:xxx"
        bind_dn: "cn=xxxxxxx, ou=xx xxxxx, ou=xxxxxx, ou=xxxxx, dc=xxxk, dc=ad, dc=xxx, dc=xx"
        user_search.base_dn: "dc=xx,dc=xx,dc=xxx,dc=xx"
        user_search.filter: "(cn={0})"
        ssl.certificate_authorities: [ "xxxxxx/xxxxxxx/elasticsearch_7.3.0/config/ca.crt" ]
        ssl.verification_mode: certificate
        files.role_mapping: "xxxxxx/xxxxxxx/elasticsearch_7.3.0/config/role_mapping.yml"
        unmapped_groups_as_roles: false
    native.native1:
        order: 1

Mateusz

2

Hi ,

We need mor information than this to be able to help you out.

I don;t have any response form elastic when I tried to logon using AD user.

How do you try to login exactly and what "I don't have any response" means exactly ? Do you try with curl? via Kibana ? What happens ? Does the browser or curl time out ?

I activate the DBUG trace for LDAP auth but still ELK log is empty.

How do you activate this and where are you looking for the logs ?

3

Hi
I trying the Kibana interface and I receive : ,,Invalid username or password. Please try again."

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap":"DEBUG", 
     "logger.org.elasticsearch.xpack.security.authz":"DEBUG" 
   } 
}

I'm checking the ELK logs.

Mateusz

4

Which log exactly might that be ? Where are you looking for them ? Do you have an elasticsearch.log ? Is it empty ? Or does it just not contain anything ldap related ?

The more time and information you put up front to describe your issues , the quicker folks in these forums will be able to assist you in resolving them !

5

Hi
Yes I'm checking the elasticsearch.log. There is no message in elk log when I tried to use AD user.
When I try ,,elastic" user and put wrong password I receive:

[2020-04-10T13:10:05,762][INFO ][o.e.x.s.a.AuthenticationService] [elk_prod_1] Authentication of [elastic] was terminated by realm [reserved] - failed to authenticate user [elastic]

But for AD user I don't receive any information .
I deleted the native realm and use only ldap and I have the same situation. There is no any message in elk.log

Mateusz

6

Make two calls

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap":"DEBUG"
   } 
}

and

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authz":"DEBUG" 
   } 
}

instead of

7

Hi
The same, no message. It has to be sth wrong with my config. In my opion ELK use only native realm and for some reason doesn't inovke the ldap realm.
Node3:

[2020-04-10T12:21:17,197][INFO ][o.e.x.w.WatcherService   ] [elk_prod_3] reloading watcher, reason [new local watcher shard allocation ids], cancelled [0] queued tasks
[2020-04-10T12:22:46,911][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T15:31:24,140][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:03,711][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:03,732][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,667][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,685][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,707][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,880][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:59,124][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:59,132][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:02,303][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:13,577][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:13,647][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:13,658][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:40,170][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:40,234][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:58,754][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:59,586][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:59,590][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_3] Checking privileges for application kibana-.kibana

NODE2:

[2020-04-10T20:28:03,723][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:03,739][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:04,257][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,620][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,653][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,677][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,692][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:58,899][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:59,125][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:59,162][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:02,292][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:02,298][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:02,304][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:13,583][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:13,655][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:13,666][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:40,178][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:40,226][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:40,228][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:40,234][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:59,589][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_2] Checking privileges for application kibana-.kibana

NODE1

[2020-04-10T20:28:54,627][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,660][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,699][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:54,873][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:58,347][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:59,121][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:59,132][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:28:59,149][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:02,296][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:02,306][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:13,649][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:13,654][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:40,226][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:40,231][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:59,583][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:59,585][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
[2020-04-10T20:29:59,589][DEBUG][o.e.x.s.a.RBACEngine     ] [elk_prod_1] Checking privileges for application kibana-.kibana
8

Hi
I did one step more. I changed user_search.base_dn to user_dn_templates and Ldap started to respond. Now I have a problem with Ldap Authorization, I receive following msg:

[LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580

I check the password and I can logon to Ldap with user and password that I specified in ELK config.
Password was added by

bin/elasticsearch-keystore add xpack.security.authc.realms.ldap.ldap1.secure_bind_password

Is it possible to read the pass from keystore. The password has 26 signs and maybe some special character was changed.

Mateusz

9

That's interesting. I can't see how this could be the case, we would print things in the log either way.

I check the password and I can logon to Ldap with user and password that I specified in ELK config.

It's most probably not the bind_dn user and password that is failing, but the (mapped from the DN template) DN and the password of the user you attempt to login with. Again, it is so much easier to get assistance in these forums if you share your whole configuration and larger parts of your logs instead of extracts.

No it's not. You can set it again if you are unsure of what you typed in the first time, but you would need to restart the cluster for the nodes to read the new values.

10

Hi
Current config:

xpack.security.enabled: true
xpack.security.audit.enabled: false
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.verification_mode: certificate 
xpack.security.http.ssl.key: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx.key
xpack.security.http.ssl.certificate: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx_certnew.cer
xpack.security.http.ssl.certificate_authorities: /xxxxx/xxxxx/elasticsearch_7.3.0/config/ca.crt
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate 
xpack.security.transport.ssl.key: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx.key
xpack.security.transport.ssl.certificate:/xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx_certnew.cer
xpack.security.transport.ssl.certificate_authorities: /xxxxx/xxxxx/elasticsearch_7.3.0/config/ca.crt 
xpack.security.authc.realms:
    ldap.ldap1:
        order: 0
        url: "ldaps://xxxx.xxxx.xxx:xxx"
        bind_dn: "cn=xxxxxxx, ou=xx xxxxx, ou=xxxxxx, ou=xxxxx, dc=xxxk, dc=ad, dc=xxx, dc=xx"
        user_dn_templates:
              - "cn={0}, dc=xxxk, dc=ad, dc=xxx, dc=xx"
        group_search:
              base_dn: "dc=xxxk, dc=ad, dc=xxx, dc=xx"
        ssl.certificate_authorities: [ "xxxxxx/xxxxxxx/elasticsearch_7.3.0/config/ca.crt" ]
        ssl.verification_mode: certificate
        files.role_mapping: "xxxxxx/xxxxxxx/elasticsearch_7.3.0/config/role_mapping.yml"
        unmapped_groups_as_roles: false
    native.native1:
        order: 1

logs:

[2020-04-14T08:25:42,668][DEBUG][o.e.x.s.a.l.s.LdapUtils  ] [elk_prod_3] LDAP bind [SimpleBindRequest(dn='cn=NXXXXXXX, dc=xxxk, dc=ad, dc=xxx, dc=xx')] failed for [LDAPConnection(connected to xxxx.xx.xxxx.xx:999)] - [LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580 ', ldapSDKVersion=4.0.8, revision=28812)]
[2020-04-14T08:25:42,670][DEBUG][o.e.x.s.a.l.LdapRealm    ] [elk_prod_3] Exception occurred during authenticate for ldap/ldap1
com.unboundid.ldap.sdk.LDAPBindException: 80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580 
	at com.unboundid.ldap.sdk.LDAPConnection.bind(LDAPConnection.java:2273) ~[unboundid-ldapsdk-4.0.8.jar:4.0.8]
	at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils$2.lambda$doRun$0(LdapUtils.java:182) ~[x-pack-security-7.3.0.jar:7.3.0]
	at java.security.AccessController.doPrivileged(AccessController.java:551) ~[?:?]
	at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.privilegedConnect(LdapUtils.java:74) ~[x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils$2.doRun(LdapUtils.java:182) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.maybeForkAndRun(LdapUtils.java:100) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.maybeForkThenBind(LdapUtils.java:198) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.LdapSessionFactory$1.loop(LdapSessionFactory.java:104) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.LdapSessionFactory.session(LdapSessionFactory.java:106) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.LdapRealm.lambda$doAuthenticate$1(LdapRealm.java:131) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.LdapRealm$CancellableLdapRunnable.doRun(LdapRealm.java:314) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:758) [elasticsearch-7.3.0.jar:7.3.0]
	at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-7.3.0.jar:7.3.0]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:835) [?:?]
[2020-04-14T08:25:42,674][WARN ][o.e.x.s.a.AuthenticationService] [elk_prod_3] Authentication to realm ldap1 failed - authenticate failed (Caused by LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580 ', ldapSDKVersion=4.0.8, revision=28812))
11

And can you bind to the LDAP server (xxxx.xx.xxxx.xx:999 ) with cn=NXXXXXXX, dc=xxxk, dc=ad, dc=xxx, dc=xx and the password you try to use in kibana ?

12

Yes, the user NXXXXXXX and pasword is from kibana. Does it mean that elk connects to LDAP with

 bind_dn: "cn=xxxxxxx, ou=xx xxxxx, ou=xxxxxx, ou=xxxxx, dc=xxxk, dc=ad, dc=xxx, dc=xx"

and LDAP returns that cannot authorize user NXXXXXXX ?
I thought that elk cannot connect to LDAP beacuse of cn=xxxxxxx and wrong password (password saved in keystore)

13

But what I'm asking is can you authenticate ( Ldap bind ) to your LDAP server with that DN and password ?

No, it doesn't mean that. It actually tries to authenticate with what is printed in the logs:

[2020-04-14T08:25:42,668][DEBUG][o.e.x.s.a.l.s.LdapUtils  ] [elk_prod_3] LDAP bind [SimpleBindRequest(dn='cn=NXXXXXXX, dc=xxxk, dc=ad, dc=xxx, dc=xx')] failed for [LDAPConnection(connected to xxxx.xx.xxxx.xx:999)] - [LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580 ', ldapSDKVersion=4.0.8, revision=28812)]

and fails. The DN is what is constructed by the user_dn_templates you have set and the username you enter in kibana , and the password is what you enter in Kibana.

14

Hi
No the User NXXXXX doesn't have privilages to access LDAP. For LDAP connection I have special user:

bind_dn: "cn=xxxxxxx, ou=xx xxxxx, ou=xxxxxx, ou=xxxxx, dc=xxxk, dc=ad, dc=xxx, dc=xx"

But from my understanding ELK should connect to LDAP usng user cn=xxxxxxx and password from keystore an than check if user NXXXXXX exist in AD and password specified in Kibana is correct. If yes the user NXXXXXX should be mapped to appropiate role . Correct ?

15

And this is why you get the failure above.

No, this is what I'm explaining. Read this part from our docs please.

In summary:

  • If you use user_dn_templates , all the requests to LDAP are made as the authenticating user.
  • If you use user search mode, then the bind_dn user is used to search for the user in the LDAP and get its DN. Once it finds the DN, elasticsearch will still try to attempt a single ldap bind with the end user DN and its password in order to verify the password is correct.

In both cases, your LDAP server configuration needs to allow users to at least bind to it so that we can check the password for correctness.

16

Ok so it seems that I'm in the same point :slight_smile:
We checked the user and password with AD admin and we don't have any ideay how to sole it.
I tried to add kereberos realm but still we finish with the same error. Any idea ? how we can solve it ?

I changed the config to following(example without kerberos) :

xpack.security.enabled: true
xpack.security.audit.enabled: false
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.verification_mode: certificate 
xpack.security.http.ssl.key: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx.key
xpack.security.http.ssl.certificate: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx_certnew.cer
xpack.security.http.ssl.certificate_authorities: /xxxxx/xxxxx/elasticsearch_7.3.0/config/ca.crt
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate 
xpack.security.transport.ssl.key: /xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx.key
xpack.security.transport.ssl.certificate:/xxxxx/xxxxx/elasticsearch_7.3.0/config/xxxxxx_certnew.cer
xpack.security.transport.ssl.certificate_authorities: /xxxxx/xxxxx/elasticsearch_7.3.0/config/ca.crt 
xpack.security.authc.realms:
    ldap.ldap1:
        order: 0
        url: "ldaps://xxxx.xxxx.xxx:xxx"
        bind_dn: "cn=xxxxxxx, ou=xx xxxxx, ou=xxxxxx, ou=xxxxx, dc=xxxk, dc=ad, dc=xxx, dc=xx"
        user_search.base_dn: "dc=xxxx,dc=ad,dc=xxxxx,dc=xx"
        user_search.filter: "(cn={0})"
        group_search:
              base_dn: "dc=xxxk, dc=ad, dc=xxx, dc=xx"
        ssl.certificate_authorities: [ "xxxxxx/xxxxxxx/elasticsearch_7.3.0/config/ca.crt" ]
        ssl.verification_mode: certificate
        files.role_mapping: "xxxxxx/xxxxxxx/elasticsearch_7.3.0/config/role_mapping.yml"
        unmapped_groups_as_roles: false
    native.native1:
        order: 1

Still have the same problem:


[2020-04-14T11:27:53,804][WARN ][o.e.x.s.a.AuthenticationService] [elk_prod_3] Authentication to realm ldap1 failed - authenticate failed (Caused by LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580 ', ldapSDKVersion=4.0.8, revision=28812))
[2020-04-14T11:28:42,960][DEBUG][o.e.x.s.a.l.LdapRealm    ] [elk_prod_3] Exception occurred during authenticate for ldap/ldap1
com.unboundid.ldap.sdk.LDAPBindException: 80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580 
	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:551) ~[?:?]
	at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.privilegedConnect(LdapUtils.java:74) ~[x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.searchForEntry(LdapUtils.java:261) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.support.LdapUtils.searchForEntry(LdapUtils.java:213) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.LdapUserSearchSessionFactory.findUser(LdapUserSearchSessionFactory.java:227) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.LdapUserSearchSessionFactory.getSessionWithPool(LdapUserSearchSessionFactory.java:79) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.PoolingSessionFactory.session(PoolingSessionFactory.java:100) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.LdapRealm.lambda$doAuthenticate$1(LdapRealm.java:131) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.xpack.security.authc.ldap.LdapRealm$CancellableLdapRunnable.doRun(LdapRealm.java:314) [x-pack-security-7.3.0.jar:7.3.0]
	at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:758) [elasticsearch-7.3.0.jar:7.3.0]
	at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-7.3.0.jar:7.3.0]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:835) [?:?]
[2020-04-14T11:28:42,963][WARN ][o.e.x.s.a.AuthenticationService] [elk_prod_3] Authentication to realm ldap1 failed - authenticate failed (Caused by LDAPException(resultCode=49 (invalid credentials), diagnosticMessage='80090308: LdapErr: DSID-0C090446, comment: AcceptSecurityContext error, data 52e, v2580 ', ldapSDKVersion=4.0.8, revision=28812))
17

Well now you can see the logs, which you couldn't before so it's a step forward.

Which user and which password?

The way your configuration is set now, you would need to pass the CN of an ldap user as the username and their password in the kibana login screen .

EDIT: Taking a closer look at your stack trace, it seems like the issue is with your bind_dn user and secure_bind_password. Have you verified that you can connect to your AD with that i.e. with

ldapsearch -D "cn=xxxxxxx, ou=xx xxxxx, ou=xxxxxx, ou=xxxxx, dc=xxxk, dc=ad, dc=xxx, dc=xx" -W -H ldaps://xxxx.xxxx.xxx:xxx

?

Maybe try and add xpack.security.authc.realms.ldap.ldap1.secure_bind_password again , in case you typed it wrong the first time ? ( It does require a restart so that elasticsearch reads the new value from the keystore )

the kerberos realm would not return an ldap error ,so again please add details and configuration when you are asking for help as it is really hard for anyone to assist you by guessing. I would suggest that we stick to ldap for now and resolve it instead of trying to configure all kinds of realms.

18

OK
you are right, too much information. So maybe step by step.
Could you add sample configuration for ldap where

  1. Dedicated technical user is responisble for connection between ELK and AD
  2. Users that we specify in Kibana will be authorized in AD (based on connection from point 1)

Mateusz

19

There is no way to do that.

In simpler terms there is no way to "Connect with this technical user and have it verify that the username and password the end user entered is correct" in LDAP.

What normally happens instead is :

  1. End user enters username and password in Kibana
  2. Elasticsearch connects to your LDAP server as bind_dn using the secure_bind_password and searches for entries that match the LDAP filter (cn=username) ( because you have configured user_search.filter: "(cn={0})" )
  3. If it finds an entry, it reads its DN, which is the DN of the end user.
  4. Elasticsearch attempts to authenticate to LDAP ( performing an LDAP bind ) with the DN it found in 3 above, and the password that the user entered in 1 above.
  5. If the LDAP bind is successful then the user authentication is successful, if not, then the user is not authenticated.

Your current issue however is that you have configured this "technical user" ( it's called the bind_dn user in our case) with a wrong password and it fails to connect to your LDAP server in step 2 above.

20

Hi
Sorry for long no response . I did a lot of tests and I found that the problem is in elk keystore,
The rules for password requires 26 signs and I think this is the problem, password is too long. I checked with 15 signs password and auth works. Could You check the limitation in elk keystore ?