Arnaud Cogoluegnes (Migrated from SEC-1005) said:
seems simple binding (without retrieving roles) does not work anymore. This would work in 2.0.3:
As well as this:
Authentication attemps now launches the following exception: LDAP: error code 80 – failed on search operation: Unexpected exception.]; remaining name ’’
Adding the group search base makes both working:
Perhaps something to do with SEC-963 (http://jira.springframework.org/browse/SEC-963).
Being not a LDAP guru, I attached the ldif just in case my directory is not correct.
Luke Taylor said:
This doesn’t seem to be a problem with the existing unit tests where they don’t provide the group-search-base. Could you possibly provide a test case which demonstrates the problem? The full configuration and whether you are using an embedded server or some other external server would also be useful.
Arnaud Cogoluegnes said:
I enclosed a small Maven 2 project:
– launch mvn test (works because Spring Security version is 2.0.3)
– change Spring Security version to 2.0.4 in pom.xml
– launch mvn test (does not work any more :-( )
The full exception I get when running with your test and 2.0.4 is
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.693 sec <<< FAILURE!
testLdapTests(org.springframework.security.SimpleBindingTest) Time elapsed: 1.668 sec <<< ERROR!
org.springframework.security.AuthenticationServiceException: Uncategorized exception occured during LDAP processing; nes
ted exception is javax.naming.NamingException: [LDAP: error code 33 – failed on search operation: Unexpected exception.:
baseDn : ‘’
filter : ’(18.104.22.168=cn=acogoluegnes, ou=people, o=tudu) ’
scope : whole subtree
typesOnly : false
Time Limit : no limit
Deref Aliases : deref Always
attributes : ’javaRemoteLocation’, ‘javaSerializedData’, ‘objectClass’, ‘cn’, ‘javaClassName’, ‘javaCodeBase’, ’
javaClassNames’, ‘javaReferenceAddress’, ‘javaFactory’
org.apache.directory.server.core.interceptor.InterceptorException: Unexpected exception. [Root exception is java.lang.Cl
(always post the full exception trace in preference to the error message). So the cause is a ClassCastException within Apache
So this looks like an internal problem with Apache Directory, possibly because you are using their AbstractServerTestCase.
I was able to get the supplied ldif file working with the following test code:
context = new InMemoryXmlApplicationContext(“ ”);
AuthenticationManager authManager = (AuthenticationManager) context.getBeansOfType(AuthenticationManager.class).values().iterator().next();
I don’t think there is a Spring Security problem here – at least there is no evidence of one.
It’s worth adding the following log4j.properties file to your maven test resources directory so you can see what’s going on – particularly what Apache DS is doing:
log4j.rootLogger=INFO, stdout, fileout
Closing the issue as the original error is coming from ApacheDS. If you come up with some more detailed evidence of a problem please open a new issue.
Peter Mularien said:
FWIW I was able to reproduce issues similar to this with ApacheDS when I did not specify a group-search-base. It seems that ApacheDS doesn't deal well with searches that don't have an explicitly stated root (aka partition).