hi,
i’m using AD and my AD admin told me that 3 consecutive failed tries will lock me in the AD.
when i run single “curl” command with wrong password i can see in the elastic log 6 rows:
@sdba2 This is a known issue: the LDAP connector only caches correct credentials.
Fortunately, this has a fix in the current master branch. Would you like to be the first one to test it? In that case please tell me the ES version you are using.
we are now using version 1.16.27 and facing the same issued as with 1.16.17 .
we have some users which were locked in active directory after 1 failed login to kibana (using ROR) .
tough I tried only one time to login, I see that the log contains 10 entries from the same hours:
[error][t.b.r.a.d.l.u.unboundidauthenticationldapclient] ldap authenticate operation failed: ldaperr dsid-…
after that my user locked .
is there a parameter which I can set in one of the configuration files so ROR will send only one authentication request to the active directory ?
looks fine now , thanks a lot .
I see only one failed entry in elastic log now .
so just to confirm , when I set the parameter to 300 , it means that only after 5 minutes the ROR will send automatically another request to the active directory ?
Yes that’s correct. We cache both valid and invalid credentials into a LRU cache which is limited in time (5min in your case) and space (some thousands entries).
Hey, I’ve started experiencing this problem again.
I’m currently using Elasticsearch 6.8.4 with ReadOnlyRest 1.18.8.
The cahce_ttl_in_sec parameter is present in the ROR configuration with a non-zero value, but while it does solve the problem in previous versions, it stoppped doing so in this version.
I am unable to send our exact configuartion. cache_ttl_in_sec is set to 30 seconds. This configuration worked in version 1.17.6,1.18.2
I have yet to check 1.18.9 and 1.18.10 but did not see any fix/change that seems related.
After a bit of further testing, I believe this happens mostly when trying to log in from Kibana (using the enterprise plugin of the same version), as opposed to any request.
If there are any specific lines in the configuration that are of interest to you that I should check, then please specify those.
“cache_ttl_in_sec” can set for whole LDAP configuration (aka LDAP connector) or per ldap rule. I understand you have configured it in ldap definition in “ldaps” section only, right?
And I understand that the incorrect ROR behaviour is as follow:
you are calling ROR with correct LDAP user but wrong credentials (or login through Kibana - whatever)
LDAP server is configured to lock the user in after 3 bad attempts
the user is locked in after the one request
In this scenario it’d be helpful to know how many LDAP rules was being called by ROR. It could mean that cache doesn’t work within handling one request which has to check several blocks with LDAP rules.
Or maybe:
you are calling ROR with correct LDAP user but wrong credentials
LDAP server is configured to lock the user in after 3 bad attempts
after 1 attempt the user is not locked in yet
within 30s (configured cache ttl) you repeat the same ROR request twice and your user becomes locked in (means that cache doesn’t work between following requests)
As you can see detailed description of your case would be helpful to reproduce your issue.
We have a single LDAP rule being called, this rule does have multiple hosts - but I do not think this is relevant.
We are calling ROR with a correct LDAP user but wrong credentials - LDAP is configured to lock the user in after 3 bad attempts - after 1 attempt the user is locked (even if the correct credentials are entered within 5 seconds, in which case it would either log you in, then a few seconds later log you out, or just outright lock you before that)
This problem occurs only when using the kibana login page.
When attempting to login (with correct LDAP user, but wrong credentials) through 3rd party tools, CURL requests, regular REST request, etc. the error does not occur and the user is not locked upon the first failed attempt