@sscarduzio I still dont see the user id logged in ROR audit index. Also, in ES log file, I see this below error logged numerous times (almost 2000+). Interestingly, when using AD group, it works fine for some users in same AD group. But others continuously get password prompts and then forbidden error message from ROR.
[2020-01-20T04:22:20,324][ERROR][t.b.r.a.b.d.l.i.UnboundidLdapAuthenticationService] [MYNODENAME] LDAP authenticate operation failed - cause [80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580 ]
Also, noticed that there was a NULL character written after v2580 (at the end, but before ]) because of which we are not able to copy from log directly.
I tried 1.19.0, but had to rollback as we ran into a major issue. We started getting Index not found error, when running queries from Kibana for all queries. We have LDAP rules setup for users.Typically, we would get a prompt for user to enter the user id/pwd. But after upgrade to 1.19.0, we are directly getting “index_not_found_exception”. In the index name, we see that index name is different than what we are querying. If we ran GET on myindex/_search, then the index name would show myindex_ROR_cRx35NQiOa.
We are using 7.2.0 on Windows 2012 R2, running default JDK.
I will try to send it tomorrow. In previous instances, we would have first got a forbidden message behind the scenes (we can see it in log), but in Kibana it would have prompted for username/password immediately. Once we provide a valid username/password, it would then executive the query and return results. In new version, since there is no prompt at all, there is no way for user to enter credentials.
yes, but this is not valid any more. User should have a feeling that he is alone on the cluster, so when he asks for an index which is not allowed for him, he should see the same response when he calls an index which really doesn’t exist.
But without capturing user credentials, how can you even determine that user is not allowed to view the index? Without prompting the user to input the id/pwd, where are you capturing who has logged in? This essentially makes the free version unusable from Kibana, if you will no longer prompt for user id/pwd input.
We were mainly focused on improving our ROR Kibana plugin, that’s why the changes have happened. Maybe you can describe how do you use Kibana with ES ROR, so we can think how we could support you case (and similar) in the newest version.
We are using Kibana for running ES queries and provision our users using LDAP AD groups. Few indices are open to all and but most indices having sensitive data is protected using different ROR blocks. For the sensitive data indices, we are required audit any kind of reads by individual users.
So typically, when users goes into Dev tools in Kibana and try to run any ES queries, if they dont have access to index, they would be prompted to enter the id/pwd for the first time. That gets validated against LDAP via ROR. So subsequently, they wouldn’t be prompted again till their session remains active. Similarly, if they try directly go to discovery tab in Kibana for the first time and had tried an index pattern, it would prompt them for id/pwd. This is how we were using ROR with Kibana.
Since we dont use any Kibana plugin and if you will no longer show the prompt where you capture the id/pwd, we would never be able to use anything in KIbana as every thing will be treated as index not found as you would never receive any kind of user credentials. Request you to please look into this to atleast provide option to simulate the old behavior of showing user prompt (even if that means adding some additional configuration, which wont be needed for your Kibana pro plugin users, since you anyway have a login page there).
Yes, I thought about one additional settings option to give ROR a hint that it should return 403 instead of 404. But we should analyse potential corner cases. Will add to backlog.
So, it seems that now, you have to stay on 1.18.x.
Thanks @coutoPL For now, we will be rolling back to 1.18.7 (as that is what we previously had before upgrading to 1.19.0) till you provide this option.
Also, how do we download a prior version of ROR? From the download page, it always send you the latest link for download.
@coutoPL ROR used to have this parameter before. I am not sure if this still works or was it removed subsequently. I think, we will need something like this to solve our prompt issue.
Yes, prompt_for_basic_auth is still valid settings. Default value is true.
As you proposed, we have changed the behaviour of ROR when the setting is enabled. Now, instead of 404 you get 401, so browser will be able to show native basic auth dialog.
please, test it and let us know how it works for you:
