Bug ID: JDK-8275535 Retrying a failed authentication on multiple LDAP servers can lead to users blocked

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 11	JDK 17	JDK 19	JDK 8	Other
11.0.18Fixed	17.0.12-oracleFixed	19 b23Fixed	8u421Unresolved	openjdk8u372Fixed

After JDK-8160768, the behavior upon a failed LDAP authentication changed: instead of aborting the operation with an AuthenticationException exception, all available LDAP servers are tried with the same credentials. Note that the credentials might be wrong because of an error when the user entered them (i.e.: a typo). If this is the case, the user may be blocked on all LDAP servers after a single operation because of exceeding the maximum number of authentication failures. In my view, an authentication error means that the LDAP server is alive and there is no need to iterate to a different endpoint.

[~sgehwolf] I have resubmitted the PR and it has been approved already.
17-02-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk8u-dev/pull/268 Date: 2023-02-16 08:56:58 +0000
16-02-2023
[~abakhtin] The PR is closed and wasn't reviewed, please add the approval label only once it's ready for approval. Removing the fix request label meanwhile.
15-02-2023
Fix Request (8u) I would like to backport this fix to 8u to restore behavior before JDK-8160768 javax/naming regression tests are passed successfully
09-02-2023
Fix request (11u, 17u) (on behalf of Ryan Flegel, no JBS user) I would like to backport this change because I have been affected by a bug (JDK-8275535) introduced by JDK-8160768. It is causing users to get locked out too quickly since incorrect credentials are being sent to every LDAP server configured. I have tested the patch by stepping through the scenario and confirming in the debugger that the behaviour is the same as before JDK-8160768. I have also run javax/naming, tier1 and tier2 tests locally (build/macosx-x86_64-server-release). javax/naming - All passed. tier1 - GTests Hotspot tests failed since I did not have it configured tier2 - There were 15 unrelated test failures in java.lang, java.net, java.nio and sun.net
12-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk8u-dev/pull/117 Date: 2022-09-06 19:30:06 +0000
06-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/654 Date: 2022-09-06 18:59:49 +0000
06-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1351 Date: 2022-08-31 20:54:47 +0000
06-09-2022
Changeset: 3be394e1 Author: Martin Balao <mbalao@openjdk.org> Date: 2022-05-12 16:16:49 +0000 URL: https://git.openjdk.java.net/jdk/commit/3be394e1606dd17c2c14ce806c796f5eb2b1ad6e
12-05-2022

CSR :	JDK-8276959 - Retrying a failed authentication on multiple LDAP servers can lead to users blocked
Relates :	JDK-8160768 - Add capability to custom resolve host/domain names within the default JNDI LDAP provider