Ldap - wrong password and immdiate lock in AD

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:

[error][t.b.r.a.d.l.u.unboundidauthenticationldapclient] ldap authenticate operation failed: ldaperr dsid-…

and i immediately locked.

why one command tries to run couple of times?
can i configure somewhere that one command will try one authenticate ?


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

i’m using es 6.1.1 and ror 1.16.17

OK Try this please https://readonlyrest-data.s3-eu-west-1.amazonaws.com/tmp/readonlyrest-1.16.18-pre1_es6.1.1.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJEKIPNTOTIVGQ4EQ/20180319/eu-west-1/s3/aws4_request&X-Amz-Date=20180319T150225Z&X-Amz-Expires=604800&X-Amz-SignedHeaders=host&X-Amz-Signature=3618cce5dd2cb8b429d3f22d220e58acb9ef98bc33815d8e3a974614f7b54404

Hi there ,

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 ?

Thanks .

@sdba2 Have you enabled caching?

if I do ctrl+shitf+i and then go to network tab I see checkbox of “disable cache” is not set . that means that cache is enabled, am I right ?

I mean the LDAP cache in the readonlyrest.yml YAML settings. I.e. cache_ttl_in_sec in the docs.

I’ve just checked , this parameter is set to 0 .

set it up to sensible value i.e. 300

ok , how this settings affects the product and the way it behaves against the active directory ?

we keep an internal in-memory cache in the LDAP connector, the credentials are checked against the cache before reaching out to the LDAP server.

The credentials are never stored in clear though, they’re hashed.

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.

Are you able to send your configuration, please?
Does it mean that 1.18.7 it works, but not in 1.18.8? Did you check 1.18.9 or 1.18.10?

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


Great. That’s a detailed description I was looking for. I’ll try to reproduce your issue and let you know if I find sth. Thanks