Some issues with version 1.16.27


when i work with version 1.16.21 (es & kibana) everything works fine.

i’ve update to 1.16.27 (es & kibana) and the user get :
Could not login: "Forbidden (403) "

in the logging index i can see :
“origin”: kiban_server_ip,
“match”: false,
“final_state”: “FORBIDDEN”,
“destination”: “”,
“task_id”: 7099,
“type”: “RRAdminRequest”,
“req_method”: “GET”,
“path”: “/_readonlyrest/metadata/current_user”,
“indices”: [],
@timestamp”: “…”,
“content_len_kb”: 0,
“error_type”: null,
“processingMillis”: 39,
“action”: “cluster:admin/rradmin/refreshsettings”,
“block”: “default”,
“id”: “…”,
“content_len”: 0,
“user”: “user1”

the user is identified by ldap.

important : i’m working with the SAME readonlyrest.yml in both versions !

when working with version 1.16.21 it works, when upgrading to 1.16.27 it failes.

what am i missing ?

(Simone Scarduzio) #2

Can you show the full FORBIDDEN log line? including the history (“HIS”)


i couldn’t find a HIS/history line in the elastic log file nor in the kibana log file.

the closest thing is the “acl_history” field i found in the index.
it contains the acl’s blocks from my readonlyrest.yml.

(Simone Scarduzio) #4

yes indeed, can you share the content of that field? It basically shows a trace of how the request was evaluated by the ACL, that is, what rules and what blocks matched and in what chronological order.


[WEBSITE SEARCH BOX::->[indices->true, actions->false]],
[allow all for admin->[ldap_authentication->false]],
[for ROR cleanup->[ldap_authentication->false]],
[for monitoring->[ldap_authentication->false]],
[requests from user for indices d*->[ldap_authentication->false]],
[requests from user for indices a*->[ldap_authentication->false]],
[requests from user for indices m1*->[ldap_authentication->false]],
[requests from user for indices p*->[ldap_authentication->false]],
[requests from user for indices m2*->[ldap_authentication->false]],
[requests from user for indices i*->[ldap_authentication->false]]

(Simone Scarduzio) #6

Great, thank you @sdba2!
And what block should normally (in 1.16.21) this request by “user1” match?
Is this a valid LDAP user that ldap_authentication should match?


the block with index d*.
the user is a valid ldap authentication and it uses ldap to authenticate.
(when running : curl -u user1:pw1 … it works)

(Simone Scarduzio) #8

This works?

curl -vvv -X GET 'http://es:9200/_readonlyrest/metadata/current_user' -u user1:password

Can you show me the output?

* about to connect() to  server1 port 9200 (#0)
*   trying connected
* connected to server1 ( port 9200 (#0)
* trying connected
* server auth using basic with user 'user1'
> get /_readonlyrest/metadata/current_user HTTP/1.1
> authorization: basic <some hash value>
> user-agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 nss/3.18 basic ecc zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> host: server1:9200
> accept: */*
< http/1.1 403 forbidden
< content-type: application/json; charset=utf-8
< connect-length: 103
* connection #0 to host server1 left intact
* closing connect #0
{"error":{"root_cause":[{"reason":"rejected by ror !!!"}],"reason":"rejected by ror !!!"},"status":403}

(Simone Scarduzio) #10

Strange, what ES version is this?
Does it reject similar requests for locally defined users too? Or is it just an LDAP thing?


this is ES 6.1.1

when i’m using another user (also ldap user) and his acl looks like :

name: “ldap1”
groups: [“A123”]
indices: ["*"]
action: ["*"]

it works (kiban login and the curl command)

for user1 the acl looks like:

name: “ldap1”
groups: [“A456”]
indices: [“d*”,".kibana*"]
actions: [“indices:admin/*”,“indices:data/write/*”,“indices/data/read/*”,“cluster:monitor/*”,“indices:monitor/*”]
kibana_hide_apps: [“readonlyrest_kbn”,“timelion”]

and it fails to login to kiban and the curl also fails

(Simone Scarduzio) #12

Ok mystery solved.
You are not using kibana_access macro rule, and you are using raw actions. I highly recommend that you remove the actions rule in favour of a kibana_access: rw/ro/ro_strict/admin.

Please read the explanation in the docs about what kibana_access does and why it’s preferable to simple actions when the objective is to allow a Kibana session to a user.