On Wed, 9 Feb 2022 15:05:24 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. > > Thanks @michael-o for your input. I see the observations that you raised. In > my view, we should revert to the previous behavior (as there are users > currently affected by the change), and perhaps we can discuss future > improvements from there, based on actual cases. > > @AlekseiEfimov can you please review this change? We need the formal > review-approval to move forward. @martinuy Agree ------------- PR: https://git.openjdk.java.net/jdk/pull/6043
