Some issues with version 1.16.27


#1

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”: “0.0.0.0”,
“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”)


#3

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.


#5

“acl_history”:
"
[::KIBANA-SRV::->[auth_key->false]],
[::RO::->[auth_key->false]],
[::RW::->[auth_key->false]],
[::ADMIN::->[auth_key->false]],
[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?


#7

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?


#9
* about to connect() to  server1 port 9200 (#0)
*   trying 1.1.1.1... connected
* connected to server1 (1.1.1.1) port 9200 (#0)
* trying 1.1.1.1... 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?


#11

this is ES 6.1.1

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

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

it works (kiban login and the curl command)

for user1 the acl looks like:

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