On Tue, 8 Feb 2022 13:51:57 GMT, Martin Balao <mba...@openjdk.org> wrote:
> > @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't > > everything protocol related a fail-fast issue? E.g., if the socket is up > > and running, but the LDAP message is rejected can we assume that all > > subsequent servers for the same resolution will reject the request as well > > before authentication has happened? > > It looks to me that it's not only a fail-fast issue because the state on the > directory side might be altered by each try, as it happened in the reported > case. In other words, the client might cause a denial-of-service blocking an > account by trying multiple times the same incorrect authentication > credentials on each resolved server. Let me add a few points for consideration from my usecases, since I don't use any password-based authentication with SASL and Active Directory only: * `SASL EXTERNAL`: What if the certificate is rejected? Trust store is not properly populated, CRL misconfigured, etc. Will an exception also thrown here? * `SASL GSSAPI/GSS-SPNEGO`: Dir server does not manage creds, but KDC does. I am thinking whether fail fast is reasonable. SPN not registered, next server might have. replay/out of sequence, etc. > In regards to the 2nd question, I guess that we cannot assume that. But the > revert is intended for failed authentication only. But the auth is part of the LDAP message as well since the auth does not happen out of band. I would expect that any non-transport issue should fail fast. > Is there a risk that you foresee by reverting the failed-authentication > behavior back to pre-JDK-8160768? Not really, I virtually never had problems, thought might need annotations when this does not work, see above. ------------- PR: https://git.openjdk.java.net/jdk/pull/6043
