Upgrade from v5.1.1 to v5.6.4 disabled role based access

Elastic Stack Elasticsearch
1

We're testing upgrades from v5.1.1 to v5.6.4 and we had all role based access working before the upgrade, but afterwards, no authentication/authorisation succeeded.

$ curl -s https://turbo:Secret@mycluster/myindex | jq . 
{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "action [indices:admin/get] is unauthorized for user [turbo]"
      }
    ],
    "type": "security_exception",
    "reason": "action [indices:admin/get] is unauthorized for user [turbo]"
  },
  "status": 403
}

I'm still running on the trial license that was generated under v5.1.1:

$ curl -s https://mycluster/_xpack/license
{
  "license" : {
    "status" : "active",
    "uid" : "acb1b8f6-8667-49ef-b99a-847aba749c61",
    "type" : "trial",
    "issue_date" : "2018-04-04T17:52:15.919Z",
    "issue_date_in_millis" : 1522864335919,
    "expiry_date" : "2018-05-04T17:52:15.919Z",
    "expiry_date_in_millis" : 1525456335919,
    "max_nodes" : 1000,
    "issued_to" : "dbase-tst",
    "issuer" : "elasticsearch",
    "start_date_in_millis" : -1
  }
}

There's no indices that needs upgrading:

$ curl -s https://elastic:Secret@dbase-tst.pharmpress.net/_xpack/migration/assistance | jq .
{
  "indices": {}
}

The relevant X-Pack configuration:

root@coordinating_host_one:/etc/elasticsearch/coordinating_host_one# grep ^xpack elasticsearch.yml
xpack.graph.enabled: false
xpack.monitoring.enabled: true
xpack.monitoring.exporters.my_local.type: local
xpack.monitoring.exporters.my_local.use_ingest: true
xpack.security.audit.enabled: true
xpack.security.audit.outputs:
xpack.security.authc.anonymous.authz_exception: false
xpack.security.authc.anonymous.roles: anon
xpack.security.authc.anonymous.username: anon
xpack.security.authc.realms.ldap1.bind_dn: "<AUTH_DN>"
xpack.security.authc.realms.ldap1.bind_password: "Secret"
xpack.security.authc.realms.ldap1.group_search.base_dn: "<BASE_DN>"
xpack.security.authc.realms.ldap1.group_search.user_attribute: cn
xpack.security.authc.realms.ldap1.order: 1
xpack.security.authc.realms.ldap1.ssl.certificate_authorities:
xpack.security.authc.realms.ldap1.timeout.ldap_search: "15s"
xpack.security.authc.realms.ldap1.timeout.tcp_connect: "15s"
xpack.security.authc.realms.ldap1.timeout.tcp_read: "15s"
xpack.security.authc.realms.ldap1.type: ldap
xpack.security.authc.realms.ldap1.unmapped_groups_as_roles: false
xpack.security.authc.realms.ldap1.url: "ldaps://myldapserver"
xpack.security.authc.realms.ldap1.user_search.attribute: uid
xpack.security.authc.realms.ldap1.user_search.base_dn: "<BASE_DN>"
xpack.security.authc.realms.local.order: 0
xpack.security.authc.realms.local.type: file
xpack.security.enabled: true
xpack.security.http.filter.allow: "10.114.2.0/16"
xpack.security.http.filter.deny: "_all"
xpack.security.http.filter.enabled: true
xpack.security.transport.filter.allow: "10.114.2.0/16"
xpack.security.transport.filter.deny: "_all"
xpack.security.transport.filter.enabled: true

I'm member of the 'admins' group, which have the following access and one of my developers is in the 'devs' group:

root@coordinating_host_one:/etc/elasticsearch/x-pack# cat roles.yml
admins:
  cluster:
    - all
  indices:
    - names:
        - "*"
      privileges:
        - all
devs:
  cluster:
    - manage
  indices:
    - names:
        - "*"
      privileges:
        - manage
        - read
        - view_index_metadata
[...]

This worked on v5.1.1. Is there another way of doing it now or what could I have missed?

2

Given the error message:

action [indices:admin/get] is unauthorized for user [turbo]

it appears that the issue is an authorization one, but not an authentication problem.

The most likely cause of your problem is either:

  1. that we're not resolve your LDAP groups correctly
  2. that the mapping from groups to roles is not correct.

I suspect the latter as
(a) it seems more likely that this would be a problem in an upgrade,
(b) you didn't show it in your post, so it's possible that you haven't checked it yet

The first step towards resolution would be to use the Authenticate API to check your groups and roles.
That should narrow down the cause:

  • If you have no ldap_groups, then something is wrong with the way we're resolving groups from your LDAP directory
  • if you have the correct ldap_groups, but no roles, then something is wrong with your role mapping (see role_mapping.yml)
  • if you have the correct ldap_groups and the correct roles, but cannot perform the actions you expect, then something is wrong with your role definition (see roles.yml)
3

Yeah, so it seems (new) ES can't seem to find my groups:

$ curl -s https://turbo:Secret@mycluster/_xpack/security/_authenticate | jq .
{
  "username": "turbo",
  "roles": [],
  "full_name": null,
  "email": null,
  "metadata": {
    "ldap_dn": "uid=turbo,ou=People,BASEDN",
    "ldap_groups": []
  },
  "enabled": true
}

My role_mapping.yml:

admins:
  - "cn=admins,ou=Groups,ou=System,BASEDN"
devs:
  - "cn=devs,ou=Groups,ou=System,BASEDN"

The LDAP part of elasticsearch.yml:

xpack.security.authc.realms.ldap1.bind_dn: "uid=elasticsearch,ou=People,ou=System,BASEDN"
xpack.security.authc.realms.ldap1.bind_password: "Secret"
xpack.security.authc.realms.ldap1.group_search.base_dn: "BASEDN"
xpack.security.authc.realms.ldap1.group_search.user_attribute: cn
xpack.security.authc.realms.ldap1.order: 1
xpack.security.authc.realms.ldap1.ssl.certificate_authorities:
  - x-pack/pharmpress.net.pem
xpack.security.authc.realms.ldap1.timeout.ldap_search: "15s"
xpack.security.authc.realms.ldap1.timeout.tcp_connect: "15s"
xpack.security.authc.realms.ldap1.timeout.tcp_read: "15s"
xpack.security.authc.realms.ldap1.type: ldap
xpack.security.authc.realms.ldap1.unmapped_groups_as_roles: false
xpack.security.authc.realms.ldap1.url: "ldaps://ldap.domain.tld"
xpack.security.authc.realms.ldap1.user_search.attribute: uid
xpack.security.authc.realms.ldap1.user_search.base_dn: "BASEDN"

In 5.1, the attribute xpack.security.authc.realms.ldap1.group_search.user_attribute used to be just ...attribute. The log say "did you mean ...".

4

Ok, so some trial and error (and reading the documentation a few times) gave me this:

Changing

xpack.security.authc.realms.ldap1.group_search.attribute: cn

to

xpack.security.authc.realms.ldap1.group_search.user_attribute: <empty>

solved it. I can now authorise properly. Thanx for the pointers! I didn't see this in the upgrade documentation though... Bug (in the doc)?

5

I think what has happened is that you ran into the breaking security change from 5.2

validation of security related settings has been tightened.

The old setting you had in v5.1.1 (group_search.user_attribute) didn't actually do anything, but also wasn't rejected.
During the upgrade to 5.6.4, we picked up that this isn't a valid setting, and suggested "did you mean ..." but actually what you really wanted to do was just delete it.

6

validation of security related settings has been tightened.

Ah, yes. In retrospect that would probably fit, but it wasn't clear that changing ...attribute to ...user_attribute and setting it to empty (or remove it altogether) was the way to go.

Anyway, working now. Thanx!

7

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