Failed LDAP authentication does not capture user id

We were previously using tech.beshu.ror.requestcontext.QueryAuditLogSerializer. Should we switch back to that if we upgrade to 1.19.0?

This one is deprecated. Please, use tech.beshu.ror.audit.instances. QueryAuditLogSerializer

Thanks. Will try and let you know.

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.


@askids yes, this was introduced in last update. See doc: readonlyrest-docs/ at master · beshu-tech/readonlyrest-docs · GitHub

This is weird, because our change should not affect old configs. Previously you will get 403 Forbidden, now you get 404 index not found.

please send us your configuration, requests which is sent to ES + ROR and ES logs.

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.


Here are direct links:

(1.18.10 was the last version before 1.19.0)

Thanks for the links. For reasons like this, i had given this suggestion before :blush:

I’ve just realised that we recently did it :slight_smile:


You guys are fantastic!! So what else hidden gems did you add and forget to inform us :rofl::rofl:

@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.

prompt_for_basic_auth: true

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:

Thank you!! I will try this on monday and confirm it.

BTW, @sscarduzio/@coutoPL, i had a honest question. Elasticsearch now ships with basic security, which includes a login page in Kibana. Open distro also ships with security plugin which comes with login page. Is it too much to ask for ROR to have the Kibana login page also made available for the OSS version? I know that its available in the pro version of the Kibana plugin. But pro version has several other features. But given that core product plus competition is providing the login page with their free versions, does it make sense for ROR not to treat having login page as a vanity feature (this may have been a differentiator 3 years back) and make it available with your OSS version? Please give it a thought.


1 Like

@coutoPL/@sscarduzio which standard serializer captures userid on forbidden requests for LDAP ? i am using tech.beshu.ror.audit.instances.QueryAuditLogSerializer and still not able to get the user id for failed attempts in audit log.