SEC-1005: Simple binding does not work anymore #1257

Closed
spring-issuemaster opened this Issue Oct 5, 2008 · 6 comments

1 participant

@spring-issuemaster

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.

@spring-issuemaster

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.

@spring-issuemaster

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 :-( )

@spring-issuemaster

Luke Taylor said:

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.:
SearchRequest
baseDn : ‘’
filter : ’(2.5.4.50=cn=acogoluegnes, ou=people, o=tudu) ’
scope : whole subtree
typesOnly : false
no limit
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
assCastException: org.apache.directory.shared.ldap.filter.SimpleNode]
at org.apache.directory.server.core.interceptor.InterceptorChain.throwInterceptorException(InterceptorChain.java
:1510)
at org.apache.directory.server.core.interceptor.InterceptorChain.access$700(InterceptorChain.java:52)
at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.search(InterceptorChain.java:1271)
at org.apache.directory.server.core.interceptor.BaseInterceptor.search(BaseInterceptor.java:202)

(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.

@spring-issuemaster

Luke Taylor said:

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();
authManager.authenticate(new UsernamePasswordAuthenticationToken(“acogoluegnes”,“mdp4arno”));

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
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.apache.directory=DEBUG
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.conversionPattern=[%p,%c{1},%t] %m%n

@spring-issuemaster

Luke Taylor said:

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.

@spring-issuemaster

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).

@spring-issuemaster spring-issuemaster added this to the 3.0.0 M1 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment