Multi-tenacy changed in 1.16.30?


(Matt) #1

I upgraded my kibana to 6.5.1 and upgraded the ror enterprise plugin as well. Everything booted back up fine and the plugin appears to work but I no longer have a drop-down on the left hand side to switch tenancy. Nothing in regards to LDAP users/groups have changed since upgrading this morning so I’m assuming it’s something between ROR and Kibana with the new version. Any ideas of where to look/troubleshoot?


(Simone Scarduzio) #2

Hi @mmorrison,

We had a lot of fixes during the latest 3 or 4 iterations in how ROR handles current groups and available groups, especially in LDAP.

Can you share what ROR version you are coming from? And also your YAML settings, so maybe we can debug this together.


(Matt) #3

Absolutely.

Coming from ROR 1.16.29 for both Elasticsearch and Kibana. ES version was 6.5.0 and now is 6.5.1, Kibana was 6.4.3 and now is 6.5.1

Here is my readonlyrest.yml

readonlyrest:
    response_if_req_forbidden: Access is not authorized. Contact DevOps if you believe this is an error.
    access_control_rules:
    - name: "::LOGSTASH::"
      auth_key_sha265: xxxxx
      actions: ["cluster:monitor/main","indices:admin/types/exists","indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create","cluster:monitor/xpack/info","cluster:admin/xpack/monitoring/bulk"]
      verbosity: error
    - name: "::KIBANA-SRV::"
      auth_key_sha256: xxxxxx
      verbosity: error
    - name: Allow Elastic Admins full priv
      ldap_auth:
          name: "myLDAP"
          groups: ["Elastic Admins"]
      verbosity: error
      kibana_access: admin
      kibana_index: ".kibana"

    - name: Allow Elastic Power Users enhanced privs
      ldap_auth:
          name: "myLDAP"
          groups: ["Elastic Power Users"]
      verbosity: error
      kibana_access: rw
      kibana_index: ".kibana_pwrusr"
      indices: [Array of Indexes]
      kibana_hide_apps: ["kibana:dev_tools", "readonlyrest_kbn"]

    - name: Allow Users basic access
      ldap_auth:
          name: "myLDAP"
          groups: ["Elastic Users"]
      verbosity: error
      kibana_access: rw
      kibana_index: ".kibana_esusers"
      indices: [ARRAY of index]
      kibana_hide_apps: ["readonlyrest_kbn", "kibana:dev_tools", "kibana:monitoring"]
    ldaps:
    - name: myLDAP
      host: "LDAP_URI"
      port: 636                                                     # optional, default 389
      ssl_enabled: true                                             # optional, default true
      ssl_trust_all_certs: false                                    # optional, default false
      search_user_base_DN: "ou=People,dc=SITE,dc=SITE"
      user_id_attribute: "uid"                                      # optional, default "uid"
      search_groups_base_DN: "ou=Roles,dc=SITE,dc=SITE"
      unique_member_attribute: "roleOccupant"                       # optional, default "uniqueMember"
      connection_pool_size: 10                                      # optional, default 30
      connection_timeout_in_sec: 10                                 # optional, default 1
      request_timeout_in_sec: 10                                    # optional, default 1
      cache_ttl_in_sec: 60                                          # optional, default 0 - cache disabled
      group_search_filter: "(objectClass=organizationalRole)"       # optional, default (cn)    
      group_name_attribute: "cn"

(Simone Scarduzio) #4

Thank you Matt, do you have a user you know the credentials of, which belongs to multiple of those groups?
If you put ES in debug mode, then you can then prepare a curl command like this:

curl -k -vvv -u myuser:passwd 'https://es-host:9200/_readonlyrest/metadata/current_user' 

You should see in the logs now if LDAP connector resolves all the groups, and the output of the curl should list the available groups (calculated as the intersection between the groups cited in your ACL, and the list of groups the user belongs to).


(Matt) #5

So, restarting ES and Kibana seemed to have brought back the drop down box to switch from Group_A to Group_B. When I click to switch tenancy into Group_B, it drops me to the login page now and says “Your request could not be authenticated, please log in again.” I log in again, get put into Group_A’s tenancy and the same thing happens when I change to Group_B again. Here is the logs I’m seeing in ES.

[2018-12-06T12:46:35,834][INFO ][t.b.r.a.ACL ] [ind-logs-client1] FORBIDDEN by default req={ ID:1710731052-1392627170#703810, TYP:GetRequest, CGR:Elastic Users, USR:mmorrison, BRS:false, KDX:null, ACT:indices:data/read/get, OA:127.0.0.1, DA:127.0.0.1, IDX:.kibana, MET:GET, PTH:/.kibana/doc/space%3Adefault, CNT:<N/A>, HDR:{authorization=, Connection=keep-alive, x-ror-current-group=Elastic Users, Host=localhost:9200, Content-Length=0}, HIS:[::LOGSTASH::->[auth_key->false]], [::KIBANA-SRV::->[auth_key->false]], [Allow Elastic Admins full priv->[ldap_authorization->false]], [Allow Elastic Power Users enhanced privs->[ldap_authorization->false]], [Allow Users basic access->[ldap_authorization->true, kibana_access->true, indices->false]] }

[2018-12-06T12:46:35,855][INFO ][t.b.r.a.ACL ] [ind-logs-client1] FORBIDDEN by default req={ ID:2038481742–954893958#703811, TYP:SearchRequest, CGR:Elastic Users, USR:mmorrison, BRS:false, KDX:null, ACT:indices:data/read/search, OA:127.0.0.1, DA:127.0.0.1, IDX:.kibana, MET:POST, PTH:/.kibana/_search?size=1000&from=0, CNT:<OMITTED, LENGTH=245>, HDR:{authorization=, x-ror-current-group=Elastic Users, Connection=keep-alive, content-type=application/json, Host=localhost:9200, Content-Length=245}, HIS:[::LOGSTASH::->[auth_key->false]], [::KIBANA-SRV::->[auth_key->false]], [Allow Elastic Admins full priv->[ldap_authorization->false]], [Allow Elastic Power Users enhanced privs->[ldap_authorization->false]], [Allow Users basic access->[ldap_authorization->true, kibana_access->true, indices->false]] }

I’ve confirmed via the command you provided and ldapsearch on my LDAP host that the user is showing as being in both groups.