Unable to authenticate with ldap realm

Your bind_dn value is wrong. (bind_dn:"uid=%s,ou=people,o=mine.com,o=email") , you can't use "templating" in this value.

  • If you want all operations to be performed against ldap as the authenticating user, you need to use user_dn_templates ( examples are in our documentation)

  • If you want to actually use a bind user to do the initial search for the authenticating user and the groups , you need to provide the specific details (DN and password) for that bind user . Our docs also have more information for this case.

Also ( unrelated to the above for now but will become relevant once you solve the above ) :

power_user:
- "cn=uid=rgujral,ou=people,o=mine.com,o=email"

"cn=uid=rgujral,ou=people,o=mine.com,o=email" is not a valid DN, "uid=rgujral,ou=people,o=mine.com,o=email" is .

Sorry I'm new to this so few things bounced over my head.
I have changed this-

power_user:

what exactly I should put in bind_dn ? I want that an authenticating user, If he or his group has a role_mapping then he should get authenticated.

I went through the doc and to set passwords for bind_dn
bin/elasticsearch-keystore add xpack.security.authc.realms.ldap1.secure_bind_password

do I need to provide my user in bind_dn and password in keystore ? or bind_dn = "uid,ou=people,o=mine.com,o=email" can be this

As I mentioned above:

  • If you want all operations to be performed against ldap as the authenticating user, you need to use user_dn_templates. You can't use the authenticating user as the bind_dn in the way you are trying to.

  • If you want to use a bind user ( Think of this as a service account that has access to your ldap and will perform some operations - like search for users and for groups ) you need to create such a user in your LDAP and provide it's DN in bind_dn and it's password in xpack.security.authc.realms.ldap1.secure_bind_password

As per my understanding, I have to use user_dn_templates as my elasticsearch will be used by many users with ldap credentials. If they or their group has some role mapped then they should get authenticated.
Correct me if I'm wrong .
I have changed the realm to below -

xpack.security.authc.realms.ldap1:
      type: ldap
      order: 0
      url: "ldap://corpds.mine.com:389"
      user_dn_templates:
        - "cn=rgujral,ou=people,o=mine.com,o=email"
        - "cn=rajeshwerrao_madoori,ou=people,o=mine.com,o=email"
      group_search:
        base_dn: "ou=groups,o=mine.com,o=email"
        user_attribute: uid
      files:
        role_mapping: /usr/share/elasticsearch/config/role_mapping.yml
      unmapped_groups_as_roles: false

  role_mapping.yml: |
    monitoring:
      - "cn=GBI Infra,ou=groups,o=mine.com,o=email"
    power_user:
      - "cn=rajeshwerrao_madoori,ou=people,o=mine.com,o=email"
      - "cn=rgujral,ou=people,o=mine.com,o=email"

Still getting the same error when authenticating with user rgujral

[2019-05-08T12:55:35,320][WARN ][o.e.x.s.a.AuthenticationService] [es-coordinating] Authentication to realm ldap1 failed - authenticate failed (Caused by LDAPException(resultCode=32 (no such object), errorMessage='no such object', matchedDN='ou=people,o=apple.com,o=email'))

Do I need to change the base_dn ?

Hi again,

Please read the documentation, it will be much easier to get this working ! user_dn_templates are templates so they need to have a part that will be substituted by something else. Your config has

user_dn_templates:
        - "cn=rgujral,ou=people,o=mine.com,o=email"
        - "cn=rajeshwerrao_madoori,ou=people,o=mine.com,o=email"

when it should have

user_dn_templates:
        - "uid={0},ou=people,o=mine.com,o=email"

so when you try to authenticate as rgujral, elasticsearch will apply the "uid={0},ou=people,o=mine.com,o=email" template to it and the DN will become "uid=rgujral,ou=people,o=mine.com,o=email" which is what you want

Thanks made the suggested changes but now getting below error;-

xpack.security.authc.realms.ldap1:
      type: ldap
      order: 0
      url: "ldap://corpds.mine.com:389"
      user_dn_templates:
        - "uid={0},ou=people,o=mine.com,o=email"
      group_search:
        base_dn: "ou=groups,o=mine.com,o=email"
        user_attribute: uid
      files:
        role_mapping: /usr/share/elasticsearch/config/role_mapping.yml
      unmapped_groups_as_roles: false


role_mapping.yml:-
    monitoring:
      - "cn=GBI Infra,ou=groups,o=mine.com,o=email"
    power_user:
      - "uid=rajeshwerrao_madoori,ou=people,o=mine.com,o=email"
      - "uid=rgujral,ou=people,o=mine.com,o=email"

when I access with user rgujral I get_

`[2019-05-08T13:34:27,002][INFO ][o.e.x.s.a.s.m.NativeRoleMappingStore] [es-coordinating] The security index is not yet available - no role mappings can be loaded

when I access with user rgujral@mine.com, I get

[2019-05-08T13:42:14,108][WARN ][o.e.x.s.a.AuthenticationService] [es-coordinating] Authentication to realm ldap1 failed - authenticate failed (Caused by LDAPException(resultCode=32 (no such object), errorMessage='no such object', matchedDN='ou=people,o=apple.com,o=email'))

Don't try this, this is not supposed to work, you need to provide the uid, not an email address.

This means that you don't have a security index created. You need to set the password for the built in users for this to happen, see our documentation on how to run the elasticsearch-setup-passwords command to help you do this. ( Assuming that you run on 6.x )

but I don't want to create a elastic built-in user. As if someone gets this username and password then he/she can access the endpoint api.

This is the very reason that I'm setting up ldap realm. Is that built in user password mandatory ?

You could then disable the reserved users with the disable user API.

Alternatively, you can make do without the internal security index ( and thus without the need to set the passwords for the reserved users ) but you'd need to

  • Set all the required roles that you might need ( apart from the built-in ones that will work ) , in a roles.yml file ( see here
  • Set all the role mappings for your users in a role_mapping.yml file as you've already done

This

`[2019-05-08T13:34:27,002][INFO ][o.e.x.s.a.s.m.NativeRoleMappingStore] [es-coordinating] The security index is not yet available - no role mappings can be loaded

is an informational warning, you should not worry since you don't have a security index in purpose.

The user always exists. You can disable it, or you can set the password to a very long random string, but it still exists because it is a built-in user.
The approach you're currently taking is to just ignore, and pretend it's not there, but it is there, and you should do something about it.

When you build a brand new cluster, and haven't set a password for the elastic user, it has a temporary random password (the bootstrap password) that is tied to the keystore of each node. That keystore is less secure that setting a real password for the user, so you are not improving your security by ignoring the setup instructions.

If you really don't want to make these users available, then run the elasticsearch-setup-passwords tool, and let it generate random passwords for each of them, throw those passwords away and then disable the users. Don't just leave them with the bootstrap password.

But, what are you going to do to manage your cluster if your LDAP server is down for maintenance?
Are you planning to use Kibana? If so, we strongly recommend that you use the builtin kibana service user for running Kibana rather than an LDAP user.

You can run without the builtin users, but I would discourage relying on LDAP as your only means of accessing and administering your cluster.

Hi @TimV
Yes we are using kibana with SAML enabled and we will try to authenticate kibana via LDAP to elasticsearch (in place of built-in kibana user). Is that fine ?
or else using kibana built in is also mandatory? I can't keep the elasticsearch.password in kibana configuration file.

Also if I run elasticsearch-setup-passwords and then immediately delete built in users then will kibana be able to connect to elasticsearch ?

@ikakavas, thanks. I'm using below role -
click_admins:
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'

I'm able to do below but not _cluster/health. (this should work as a part of monitor cluster)
curl --cacert crt.pem -u rgujral "https://es-coordinating.gbi-test.svc.lb.usrno1.mine.io:9200"
Enter host password for user 'rgujral':

{
  "name" : "es-coordinating",
  "cluster_name" : "my-cluster",
  "cluster_uuid" : "R4W64zBaRCi5iRkgWFg",
  "version" : {
    "number" : "6.3.0",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "424e937",
    "build_date" : "2018-06-11T23:38:03.357887Z",
    "build_snapshot" : false,
    "lucene_version" : "7.3.1",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

curl --cacert crt.pem -u rgujral "https://es-coordinating.gbi-test.svc.lb.usrno1.mine.io:9200/_cat/nodes"

Enter host password for user 'rgujral':

{"error":{"root_cause":[{"type":"security_exception","reason":"action [cluster:monitor/state] is unauthorized for user [rgujral]"}],"type":"security_exception","reason":"action [cluster:monitor/state] is unauthorized for user [rgujral]"},"status":403}sh-4.2#

sh-4.2# curl --cacert crt.pem -u rgujral "https://es-coordinating.gbi-test.svc.lb.usrno1.mine.io:9200/_cat/health"

Enter host password for user 'rgujral':

{"error":{"root_cause":[{"type":"security_exception","reason":"action [cluster:monitor/health] is unauthorized for user [rgujral]"}],"type":"security_exception","reason":"action [cluster:monitor/health] is unauthorized for user [rgujral]"},"status":403}

It is fine, but it means Kibana is dependant on your LDAP server, and if your directory is down for any reason, then no one can use Kibana.
If that's OK with you, then there's no problem.

How are you planning to make LDAP integration work then? Surely your LDAP-kibana user requires a password.

You can't delete the built-in users, only disable them.
You can disable any of the built-in users you wish if you are not using them. Some parts of the stack will default to using built-in users, but you can configure them to use a different user if you wish.

What does this give?

curl --cacert crt.pem -u rgujral "https://es-coordinating.gbi-test.svc.lb.usrno1.mine.io:9200/_xpack/security/_authenticate?pretty"

Can you please paste YAML definitions as code blocks (the </> button).
YAML is whitespace sensitive, and we cannot check whether your config is correct if the whitespace has been removed.

@TimV
How can I setup LDAP-kibana user (what privileges does it require, it should have same privileges as that of kibana built-in user. right ?)

How can I make kibana to connect to elasticsearch without storing any password in kibana.yml ? without storing in keystore also

if I run elasticsearch-setup-passwords auto then still do I need to provide the password in kibana.yml or kibana will somehow store in its .security index ?

I ran elasticsearch-setup-passwords auto. But I didn't mention any elasticsearch.username and password in kibana.yml.
It started kibana but it is not able to get license information from elasticsearch. I have provided elasticsearch url only.

error -

{"type":"log","@timestamp":"2019-05-09T08:29:59Z","tags":["license","warning","xpack"],"pid":1,"message":"License information from the X-Pack plugin could not be obtained from Elasticsearch for the [data] cluster. [security_exception] missing authentication token for REST request [/_xpack], with { header={ WWW-Authenticate=\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\" } } :: {\"path\":\"/_xpack\",\"statusCode\":401,\"response\":\"{\\\"error\\\":{\\\"root_cause\\\":[{\\\"type\\\":\\\"security_exception\\\",\\\"reason\\\":\\\"missing authentication token for REST request [/_xpack]\\\",\\\"header\\\":{\\\"WWW-Authenticate\\\":\\\"Basic realm=\\\\\\\"security\\\\\\\" charset=\\\\\\\"UTF-8\\\\\\\"\\\"}}],\\\"type\\\":\\\"security_exception\\\",\\\"reason\\\":\\\"missing authentication token for REST request [/_xpack]\\\",\\\"header\\\":{\\\"WWW-Authenticate\\\":\\\"Basic realm=\\\\\\\"security\\\\\\\" charset=\\\\\\\"UTF-8\\\\\\\"\\\"}},\\\"status\\\":401}\",\"wwwAuthenticateDirective\":\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\"}"}
{"type":"error","@timestamp":"2019-05-09T08:29:59Z","tags":["connection","client","error"],"pid":1,"level":"error","error":{"message":"socket hang up","name":"Error","stack":"Error: socket hang up\n    at TLSSocket.<anonymous> (_tls_wrap.js:876:25)\n    at emitOne (events.js:121:20)\n    at TLSSocket.emit (events.js:211:7)\n    at _handle.close (net.js:567:12)\n    at Socket.done (_tls_wrap.js:356:7)\n    at Object.onceWrapper (events.js:315:30)\n    at emitOne (events.js:121:20)\n    at Socket.emit (events.js:211:7)\n    at TCP._handle.close [as _onclose] (net.js:567:12)","code":"ECONNRESET"},"message":"socket hang up"}

How can I resolve this ?

curl --cacert crt.pem -u rgujral "https://es-coordinating.gbi-test.svc.lb.usrno1.mine.io:9200/_xpack/security/_authenticate?pretty"
Enter host password for user 'rgujral':
{
  "username" : "rgujral",
  "roles" : [
    "click_admins"
  ],
  "full_name" : null,
  "email" : null,
  "metadata" : {
    "ldap_dn" : "uid=rgujral,ou=people,o=mine.com,o=email",
    "ldap_groups" : [ ]
  },
  "enabled" : true
}


Configuration-

xpack.security.authc.realms.ldap1:
  type: ldap
  order: 0
  url: ldap://corpds.mine.com:389
  user_dn_templates:
    - "uid={0},ou=people,o=mine.com,o=email"
  group_search:
    base_dn: "ou=groups,o=mine.com,o=email"
    user_attribute: uid
  files:
    role_mapping: /usr/share/elasticsearch/config/role_mapping.yml
  unmapped_groups_as_roles: false

  role_mapping.yml: |
click_admins:
  - "uid=rajeshwerrao_madoori,ou=people,o=mine.com,o=email"
  - "uid=rgujral,ou=people,o=mine.com,o=email"
  roles.yml: |
    click_admins:
      run_as: [ 'clicks_watcher_1' ]
     cluster: [ 'monitor' ]
     indices:
       - names: [ 'events-*' ]
         privileges: [ 'read' ]
         field_security:
          grant: ['category', '@timestamp', 'message' ]
        query: '{"match": {"category": "click"}}'

@ikakavas, now I'm trying to authenticate via a group I'm a part of -:

xpack.security.authc.realms.ldap1:
type: ldap
order: 0
url: ldap://corpds.mine.com:389
user_dn_templates:
- "uid={0},ou=people,o=mine.com,o=email"
- "cn={0},ou=groups,o=mine.com,o=email"
group_search:
base_dn: "ou=groups,o=mine.com,o=email"
user_attribute: uid
files:
role_mapping: /usr/share/elasticsearch/config/role_mapping.yml
unmapped_groups_as_roles: false

role_mapping.yml: |
click_admins:

  • "uid=rajeshwerrao_madoori,ou=people,o=mine.com,o=email"
  • "cn=GBI APC Infra,ou=groups,o=mine.com,o=email"
    roles.yml: |
    click_admins:
    run_as: [ 'clicks_watcher_1' ]
    cluster: [ 'monitor' ]
    indices:
    • names: [ 'events-*' ]
      privileges: [ 'read' ]
      field_security:
      grant: ['category', '@timestamp', 'message' ]
      query: '{"match": {"category": "click"}}'

But not working do I have to keep any option in group_search to allow any group ?

Read this and specifically the "Also be patient" part.

It's fine to answer on your own thread after 2 or 3 days (not including weekends) if you don't have an answer.

Hi,

As David mentioned, please be patient. Also please provide more information and ask concrete questions. The more people need to dig through your posts to get information and what you are exactly asking, the more time it will take for them to get back to you or provide any meaningful suggestions.

This is not how user_dn_templates work. I have shared the documentation with you above, please read through it. One cannot "authenticate via a group". One authenticates as a user.

But not working

What is not working ?

do I have to keep any option in group_search to allow any group ?

Please take the time to describe in detail what you want to achieve.

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