No password check when DefaultTlsDirContextAuthenticationStrategy is activated

[derTobsch]

We stumbled over this problem one week ago and thought it would be nice to tell you about this.

When the DefaultTlsDirContextAuthenticationStrategy is set as authentication strategy on the LdapContextSource every password will be accepted, because there happens no bind with user credentials against ldap.

After deep debugging into your code and a lot of searching on the web, we found this post in the spring forum from Jul 18th, 2013.
http://forum.spring.io/forum/spring-projects/data/ldap/129629-ldap-with-tls-authentication-issues

mwebb describes very detailed the problem and gives an code example approach to fix this.

It appears that SimpleDirContextAuthenticationStrategy and DefaultTlsDirContextAuthenticationStrategy are not symmetrical in their behaviour. I resolved this be creating a custom TlsDirContextAuthenticationStrategy and adding a ctx.reconnect() to the applyAuthentication(), after the environment settings for a simple bind have been set, as follows:

private void applyAuthentication(LdapContext ctx, String userDn, String password) throws NamingException {
ctx.addToEnvironment(Context.SECURITY_AUTHENTICATI ON, SIMPLE_AUTHENTICATION);
ctx.addToEnvironment(Context.SECURITY_PRINCIPAL, userDn);
ctx.addToEnvironment(Context.SECURITY_CREDENTIALS, password);
// Force reconnect with user credentials
ctx.reconnect(null)
}

The problem he describes was exactly the same we had. The line ctx.reconnect(null) fixed it for us.

[alex-sherwin]

FWIW, I ran up against this problem this week as well.

Lots of hair pulling as to how the LdapTemplate.authenticate(..) suite of functions was not actually testing the specified user/password via a bind operation.

[rwinch]

Thank you for the report. Unless someone comes up with another example, I'm closing this as invalid.

Please see the explanation here #432 (comment)

[espenhw]

Five minutes of playing with @derTobsch's example project shows that this is not true; the exact same thing happens with anonymous search disabled. See my updated version here: https://github.com/espenhw/tls-bug-demo

Edit: I can also reproduce this on an OpenLDAP installation with 'disallow bind_anon' set; this is not reflected in the example project

[alex-sherwin]

Not sure why this is closed as invalid? This is pretty easy to replicate and clear to check in the code what is happening. The implementation claims to authenticate a user when it does no such thing

[rwinch]

@alex-sherwin @espenhw Thank you for the additional feedback. This is now merged into master.

Please see my follow up comments on the PR.

[mschneid]

Since Java 9 this workaround is no longer necessary. Even worse, it leads to a memory leak and an open socket. Since Java 9, every call to LdapCtx#reconnect(Control[]) initiates a new LdapClient without calling LdapClient#close(Control[], boolean) before. This leads to the situation that the former LdapClient remains alive and is never garbage collected because of the worker thread of the LDAP connection.

[rwinch]

@mschneid This issue is closed. Can you please create a new issue with details and a minimal but complete sample to reproduce?