BindAuthenticator successfully authenticates incorrect passwords on certain LDAP server configurations

Summary

Beginning in Spring Security 4.1.0, when using LDAP search-and-bind authentication strategy (BindAuthenticator), if the user attributes are returned in the first search, they are not fetched again after binding to a user.

https://github.com/spring-projects/spring-security/commit/6b436ff4099694f8bb344ca4f8c6a6782c6ed31b

This is a problem when the first search performed by the initial login user (before binding) only returns a partial set of attributes due to the LDAP server's attribute access controls. If the password attribute of the bind user is not readable by the initial login user, then the password is not in the "cached" attributes and no password comparison occurs.

Actual Behavior

When the LDAP server is configured as stated above, BindAuthenticator successfully authenticates every login attempt as long as the uid exists regardless of incorrect password.

Expected Behavior

BindAuthenticator should fail to authenticate login attempts when provided with an incorrect password.

Configuration

This bug is dependent on an LDAP server configured such that the login user does not have privileges to read a user's password attribute.

Version

Spring Security 4.0.4 works as expected.
Spring Security 4.1.4 experiences the issue.

Start at BindAuthenticator and trace the LDAP search-and-bind flow described in the issue, comparing the 4.0.4 and 4.1.4 behavior. Reproduce the restricted-password-attribute configuration and verify that an incorrect password fails authentication even when the user’s uid exists.