ROR Audit not logging user id


When using LDAP group based authentication and authorization, if the entered user id is not part of the AD groups configured in the ACL rule, ROR rejects the request (as expected). But in the ROR audit index, the user attribute is logged as null. So we wouldn’t know which user attempted that rejected request.

I am running ROR Free edition v1.16.28 on Win 2012 R2.


@coutoPL can you take care of this in the new LDAP connector?

yes, no problem - I can handle it

Forgot to mention, running ES 5.5.1.

1 Like

hi @sscarduzio/@coutoPL,

Looks like this issue is still present in the newer versions as well. Failed attempt logs does not include user id for LDAP authentication failures. I am testing with ES 7.2.0 and ROR 1.19.0.


Could you please show us and example (enable debug mode, please)? I don’t think it was fixed before, but I’m not sure I understand the issue well

Let me explain the scenario. Lets say we have a valid user, but user account is present in a different OU than what your ldap authentication is looking for. In such a case, when user attempts to enter their id/pwd, though its valid, it will not find a user match. In such a case, it will show forbidden error as no rules were satisfied, but in log, it will show user as not logged in header and userid field is not captured in the ROR audit log.

Other scenario could be straight forward where user is entering wrong id or valid id with wrong password. So it wont find a match against any rules. Again response will be forbidden, but the attempted user id is not logged anywhere.

I am using tech.beshu.ror.audit.instances.QueryAuditLogSerializer as audit serializer. This one has all the details that I need, except for cases of user id not being logged for above cases.


I think populating the user field also when no ACL block matches is a great enhancement to our audit log serializers (both plain text logs and JSON logs).

We could even think of reusing the same “user”/USR field, and operators can still distinguish between successful and attempted logins because the “final_state” field would be “FORBIDDEN”.

Completely agree. If user is reporting failures, it becomes very easy to troubleshoot the issue by looking at the audit log.

Also, on a related note, do you for see an issue, if were to add some default pipeline for the ROR audit template? We have a need to parse the query content being logged to pull few attributes from the executed query for few scenarios. So instead of writing custom log serializer, we are thinking of doing it via pipeline. Do you think will there be any overhead going this route?

Looking at code I don’t understand your discussion guys. That’s why I wanted to see a real example.

Code looks like this:

.put("user", requestContext.loggedInUserName.orElse(requestContext.attemptedUserName).orElse(requestContext.rawAuthHeader).orNull)

means that:

  • take logged user OR
  • take attempted user (from basic auth header) OR
  • take auth header if it’s not basic auth OR
  • no user found

I’m not saying that for sure it works well (maybe somewhere is a bug), but conceptually, for me, it solved all problems mentioned above. Doesn’t it?

Please see screen shot below. This is how my ROR data looks like where I am only running ROR ES without any ROR Kibana plugin. So I would get basic auth prompt in Chrome and entering invalid id/pwd combination does not log user id.

I am wondering if this is anywhere related to long standing Kibana issue where user auth header is not consistently passed. Its just a guess. In captured header, it says User not logged.

So I tried it on another server which has new version of ES and also has ROR Kibana plugin with basic auth prompt turned off. For failed attempts, its logging user id. In log, it will show user id with (attempted).

I also tried it from SOAP UI by passing incorrect password. Its logging the user id in this case as well similar to above case.

This may become a non issue once we start using ROR Kibana plugin in another 3-4 weeks. So I am okay with this not being addressed.

We were originally struggling with identifying failed login attempts by user. But eventually figured out that issue was due to user OU being different (see below issue). So even when user was part of AD group, they were unable to get past login prompt. But now with we rolling out the dashboard feature, we are getting more users from different OU and our ACL rules keep duplicating. So I would rather have you prioritize that issue over this user id issue :wink:

ok, I need one more thing: could you please show me how you configured the audit serializer?

below are the audit settings.

audit_collector: true 
audit_index_template: "'readonlyrest_audit'-yyyy-MM"
audit_serializer: tech.beshu.ror.audit.instances.QueryAuditLogSerializer

ok, it’s the serializer I was talking about.
Hmm, 1.19.0 is pretty old version of ROR. What about one of the newest?

audit settings and serializer is same on the newer version (1.21 is being used with 7.8.0 and 1.22 with 7.8.1) as well.