few months ago we opened case regarding the ldap errors we see in the elastic log files.
the conclusion was that from time to time there are hangs from the ldap servers which cause those error messages .
we decided to change the configuration file and started working with native ror user .
we have version 1.18.2 .
the config files of that user :
name : “::name of the rule::”
verbosity:error
type: allow
auth_key: username:password
indices: [“index*”]
actions ["*"]
kibana_hide_apps: [“readonlyrest_kbn”]
then we have more users which authenticated by active directory .
the problem is that from time to time we see in the elastic log file errors :
[2019-10-01T10:00:00,589][ERROR][t.b.r.a.b.d.l.i.UnboundidLdapAuthenticationService] [node_name] LDAP authenticate operation failed
then if we query the ror_audit index we get :
“acl_history”: …
“origin”: “ip address”
“match” false,
“final_state”: “FORBIDDEN”
“destination” : “ip address”
“task_id”: 123456789
“type”: “BulkRequest”
“req_method”: “POST” …
the question is why do we see those error from that specific user which is not even part of the active directory users ?
this is a native user we created and is not managed by the AD servers.
how can we avoid those errors ?
@coutoPL did we manage to isolate any reproducer test for this LDAP issue? It should clearly not behave like this in the first place.
@alonzo in order to understand why the LDAP connector is being triggered, we need to see the whole ACL, so we can see the ordering of the blocks, etc. Also, the “acl_history” is critical to understand what’s going on.
And one more thing, can you try with the newer version of ROR? Yours is quite ancient. There will be a ton of bug fixes and much better logging.
sorry for the delay , had some other urgent things to take care of .
so the version we are using is 1.18.2 for ES 6.1.1 .
it’ll take some time until we can upgrade to 1.18.5 and check if it helps .
I can’t reproduce the issue since it happens once in a while and I can’t figure why it happens. looks like that though the AD fine we get those errors , so I can’t “blame” the infrastructure.
I’ll ask if I can send you the entire ACL file.
another thing regarding that issue , is there a way to raise the trace level of the ROR ?
for example , if I query the readonlyrest_audit index I’d like to see which user was blocked .
the search doesn’t show which user was trying to access the index.
this is because it’s not trivial to be up to date. it’s kind of complicated always to have the latest version.
if I remember well when I opened this case 18.5 was the latest version so this is what we have but still didn’t implement it in our cluster. I’ll see if I can have the 18.8 .
anyhow, can you please update if there’s a way to set a higher trace or debug level ?
Thanks .
If you plan to upgrade, I don’t see any reason why you cannot upgrade to the latest version. Our config is backward compatible, so you shouldn’t have to change it. There were a lot of LDAP changes and fixes since 1.18.2, so there is a big chance that your issue is solved.