Dicover returns error [undefined] REJECT by ROR

1

Hi,

we use LDAP to identify our users .
we have user a which has read/write access to indices a*
and user b which has read/write access to indices b*

the ACL looks like that :

-name: "::KIBANA-SRV::"
  auth_key: user/password
  verbosity: error

 -name : "::RO::" 
  auth_key: ro:dev
  kibana_access: ro
  indices: {".kibana*"]
  verbosity: error

- name " .... " 
  vrbosity: error
  ldap_auth:
    name : "ldap_name"
    groups: "GROUP_A"
    indices: ["a*"]
    actions: ["indices:admin/*","indices:data/write/*","indices:data/read/*","cluster:monitor/*","indices:monitor/*"]
kibana_hide_apps: ["readonlyrest_kbn","timelion"

     .
     .
     .

 - name "request using kibana"
  verbosity: error
  type: allow
  ldap_auth:
    name : ldap_name 
    groups: ["GROUP_A"]
 indices: [".kibana"]
 kibana_access: rw
 kibana_hide_apps: ["readonlyrest_kbn","timelion"]

what else do I need to configure so user a and user b will be able to work with the “discover” in KIBANA UI ?

thanks

2

@alonzo, I’m not able to understand the question. Also the reported settings have multiple indent and spelling errors, so I can’t really analyse them.

If you have trouble because you are working with a system that is not connected to internet, consider taking a picture of the screen with your phone.

3

came back to work after few days ,
sorry, I can’t take a screenshot so I’ll correct the spelling mistakes and try to explain again what the problem is :

so the configuration file looks like this :

readonlyrest:

enable: true
response_if_req_forbidden: Rejected by ROR !!!
audit_collector: true

access_control_rules:

  • name: “::KIBANA-SRV::”
    auth_key: user_name:password
    verbosity: error

  • name : “::RO::”
    auth_key: ro:dev
    kibana_access: ro
    indices: [“.kibana*”]
    verbosity: error

  • name " rule for group_a "
    vrbosity: error
    ldap_auth:
    name : “ldap_name”
    groups: “GROUP_A”
    indices: [“a*”]
    actions: [“indices:admin/","indices:data/write/”,“indices:data/read/","cluster:monitor/”,“indices:monitor/*”]
    kibana_hide_apps: [“readonlyrest_kbn”,“timelion”]

  • name " rule for group_b "
    vrbosity: error
    ldap_auth:
    name : “ldap_name”
    groups: “GROUP_B”
    indices: [“b*”]
    actions: [“indices:admin/","indices:data/write/”,“indices:data/read/","cluster:monitor/”,“indices:monitor/*”]
    kibana_hide_apps: [“readonlyrest_kbn”,“timelion”]

  • name “request using kibana enterprise”
    verbosity: error
    type: allow
    ldap_auth:
    name : ldap_name
    groups: [“GROUP_A”,“GROUP_B”]
    indices: [“.kibana*”]
    kibana_access: admin
    kibana_hide_apps: [“readonlyrest_kbn”,“timelion”]

the question is :
if we logon to kibana with username and password of someone from group_a and go to dev tools , we do GET /_cat/indices and see the indexes of users from GROUP_A.
that’s ok and there are no problems .

if instead of DEV TOOLS we go to DISCOVER then we get an error message on top of the screen -
Discover : [undefined] Rejected by ROR!!!

so if we click MORE on that message then we see more details -
Error: [undefined] Rejected by ROR !!!
at respond (http://hostname:5601/bundles/kibana.bundle.js?v=16350:61:161556)
at checkRespForFailure (http://hostname:5601/bundles/kibana.bundle.js?v=16350:61:160796)
at http://hostname:5601/bundles/kibana.bundle.js?v=16350:55:29074
at processQueue (http://hostname:5601/bundles/commons.bundle.js?v=16350:35:132456)
at http://hostname:5601/bundles/commons.bundle.js?v=16350:35:133349
at Scope.$digest (http://hostname:5601/bundles/commons.bundle.js?v=16350:35:144239)
at Scope.apply (http://hostname:5601bundles/commons.bundle.js?v=16350:35:147018)
at done (http://hostname:5601bundles/commons.bundle.js?v=16350:35:100026)
at CompleteRequest (http://hostname:5601bundles/commons.bundle.js?v=16350:35:104697)
at XMLHttpRequest.xhr.onload (http://hostname:5601bundles/commons.bundle.js?v=16350:35:105435)

I guess there is a missing permission which I have to set for this AD group so the users will be able to see data through DISCOVER menu because maybe something is running behind the scenes .
what else do we have to set to work with DISCOVER ?

thanks.

4

The answer to this is in the Elasticsearch log, you should find a line with “FORBIDDEN”. It will show

  1. all the info about the request (action, path, indices, headers)
  2. the trace of all the rules that matched or not.
5

sorry , but if I click the DISCOVER and look for errors in the cluster_name.log under /var/log/elasticsearch then I still see errors from yesterday . the file is not updated with the current error message or the trace .
is there anywhere else I can look for ?

6

looks like the readonlyrest-audit has the data.
I’ve just started exploring and I think I found it .
I’m going to run some checks and update later if I succeeded or not .

7

so, the readonlyrest-audit index showed that the user from group_a wanted to run msearch on indexes of user from group_b.
the problem was that the default index-pattern (when you login to DISCOVER) was something which is forbidden for user_a.
we had to scroll down and choose the correct index-pattern for that user.
after that we didn’t get the error message.

Thanks .