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

**URL:** <https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386>\
**Category:** Elasticsearch\
**Created:** [April 17, 2018, 2:46pm UTC](https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386 "2018-04-17T14:46:50Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Turbo\_Fredriksson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/turbo_fredriksson/32/27696_2.png) [@Turbo\_Fredriksson](https://discuss.elastic.co/u/Turbo_Fredriksson)\
**Post date:** [April 17, 2018, 2:46pm UTC](https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386/1 "2018-04-17T14:46:50Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\
**Post date:** [April 20, 2018, 3:31am UTC](https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386/2 "2018-04-20T03:31:05Z")

</div>

> [@Turbo\_Fredriksson](#):
>
> no authentication/authorisation succeeded

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.

> [@Turbo\_Fredriksson](#):
>
> I'm member of the 'admins' group, which have the following access and one of my developers is in the 'devs' group:

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](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/security-api-authenticate.html) 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`)

---

<div class="post-metadata">

**Author:** ![Turbo\_Fredriksson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/turbo_fredriksson/32/27696_2.png) [@Turbo\_Fredriksson](https://discuss.elastic.co/u/Turbo_Fredriksson)\
**Post date:** [April 23, 2018, 11:20am UTC](https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386/3 "2018-04-23T11:20:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Turbo\_Fredriksson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/turbo_fredriksson/32/27696_2.png) [@Turbo\_Fredriksson](https://discuss.elastic.co/u/Turbo_Fredriksson)\
**Post date:** [April 23, 2018, 11:33am UTC](https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386/4 "2018-04-23T11:33:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\
**Post date:** [April 23, 2018, 12:33pm UTC](https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386/5 "2018-04-23T12:33:41Z")

</div>

> [@Turbo\_Fredriksson](#):
>
> Thanx for the pointers! I didn't see this in the upgrade documentation though... Bug (in the doc)?

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

- [Change List | X-Pack for the Elastic Stack [5.6] | Elastic](https://www.elastic.co/guide/en/x-pack/5.6/xpack-change-list.html#breaking-5.2.0)

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

---

<div class="post-metadata">

**Author:** ![Turbo\_Fredriksson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/turbo_fredriksson/32/27696_2.png) [@Turbo\_Fredriksson](https://discuss.elastic.co/u/Turbo_Fredriksson)\
**Post date:** [April 23, 2018, 12:50pm UTC](https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386/6 "2018-04-23T12:50:12Z")

</div>

> 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!

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [May 21, 2018, 12:50pm UTC](https://discuss.elastic.co/t/upgrade-from-v5-1-1-to-v5-6-4-disabled-role-based-access/128386/7 "2018-05-21T12:50:13Z")

</div>

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