The current implementation of BindAuthenticator implicitly expects that the user it binds with is allowed to read its own user object. In some environments this is not true, e.g. Microsoft's ADAM does by default not allow normal users (or user proxies) to read their own directory objects. Typically only dedicated 'manager' users are allowed to read all user objects.
In such an environment, BindAuthenticator binds to the server with the user credentials and succeeds in the first step (this is the first line of the try block in bindWithDn() ). Next, it tries to retrieve all attributes on the user object, but fails with LDAP error code 32. This is because that normal user account must not descend that far into the directory tree. This problem was described similarly also in http://forum.springsource.org/showthread.php?t=53273
What I want to suggest is that the user attributes are not retrieved through the specific user's context, but rather through the general context source (which is the manager user with the appropriate permissions).
There's one disadvantage with my approach, as an additional bind must be performed to the LDAP server (one user bind becomes one user bind + one manager bind). The advantage is that less directory privileges are required for the normal users - the bind for password checking only, and all supplemental user attributes are retrieved by the manager user.
I have a rough patch against Spring Security 2.0.5 already that I would like to discuss. I will post it shortly, after porting it to Spring Security 3.0.3.