SEC-1444: BindAuthentiator Fails for Active Directory DN Containing Special Chars #1685

Closed
spring-issuemaster opened this Issue Mar 19, 2010 · 20 comments

1 participant

@spring-issuemaster

Jeff Nadler (Migrated from SEC-1444) said:

BindAuthenticator.java (3.0.2) line 115, change userDN:

Attributes attrs = ctx.getAttributes(userDn, getUserAttributes());

to fullDn:

Attributes attrs = ctx.getAttributes(fullDn, getUserAttributes());

The reason is that when you use fullDn the DN string is generated using the LdapEncoder from Spring-LDAP. If you use the raw userDn string that encoding isn't used, so special characters in a username (admittedly rare) can prevent the user from authenticating.

@spring-issuemaster

Luke Taylor said:

The use of the fullDn will potentially fail there since the name used should be relative to the context returned by the bind. The fullDn is already used for the authentication call (the bind). It may be that we should encode the userDn value too though. Could you clarify what the actual error you are seeing is please?

@spring-issuemaster

Jeff Nadler said:

Here's the exception I get when I attempt to login as a user with a slash in his DN. All other users can authenticate without problems.

AuthenticationServiceException:
org.springframework.security.authentication.AuthenticationServiceException: Uncategorized exception occured during LDAP processing; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0
remaining name 'cn=Pinhead\, Zippy PH/HU,ou=AA,ou=A,ou=Users 135200,dc=dom1,dc=local'
at org.springframework.security.ldap.authentication.LdapAuthenticationProvider.authenticate(LdapAuthenticationProvider.java:271)
at com.attensa.core.security.MultiAuthorityAuthenticationProvider.authenticateAgainstRemoteDirectory(MultiAuthorityAuthenticationProvider.java:96)
at com.attensa.core.security.MultiAuthorityAuthenticationProvider.remoteDirectoryAuthenticationChecks(MultiAuthorityAuthenticationProvider.java:79)
at com.attensa.core.security.MultiAuthorityAuthenticationProvider.additionalAuthenticationChecks(MultiAuthorityAuthenticationProvider.java:55)
at org.springframework.security.authentication.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:139)
at org.springframework.security.authentication.ProviderManager.doAuthentication(ProviderManager.java:120)
at org.springframework.security.authentication.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:48)
at org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter.attemptAuthentication(UsernamePasswordAuthenticationFilter.java:97)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:200)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at com.attensa.web.security.ActiveUserFilter.doFilter(ActiveUserFilter.java:106)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at com.attensa.web.security.SyncDirectoryUserFilter.doFilter(SyncDirectoryUserFilter.java:65)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at com.attensa.web.security.SessionTimeoutFilter.doFilter(SessionTimeoutFilter.java:29)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:149)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.springframework.ldap.UncategorizedLdapException: Uncategorized exception occured during LDAP processing; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0
remaining name 'cn=Pinhead\, Zippy PH/HU,ou=AA,ou=A,ou=Users 135200,dc=dom1,dc=local'
at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:215)
at com.attensa.core.security.AttensaBindAuthenticator.bindWithDn(AttensaBindAuthenticator.java:130)
at com.attensa.core.security.AttensaBindAuthenticator.authenticate(AttensaBindAuthenticator.java:83)
at org.springframework.security.ldap.authentication.LdapAuthenticationProvider.authenticate(LdapAuthenticationProvider.java:252)
... 34 more
Caused by: javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0
remaining name 'cn=Pinhead\, Zippy PH/HU,ou=AA,ou=A,ou=Users 135200,dc=dom1,dc=local'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3081)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2794)
at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1011)
at com.sun.jndi.toolkit.ctx.ComponentContext.c_resolveIntermediate_nns(ComponentContext.java:152)
at com.sun.jndi.toolkit.ctx.AtomicContext.c_resolveIntermediate_nns(AtomicContext.java:342)
at com.sun.jndi.toolkit.ctx.ComponentContext.p_resolveIntermediate(ComponentContext.java:381)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:205)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:121)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:109)
at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:123)
at com.attensa.core.security.AttensaBindAuthenticator.bindWithDn(AttensaBindAuthenticator.java:108)
... 36 more

@spring-issuemaster

Jeff Nadler said:

There may be another (semi-related) bug as well. This user was originally getting parse exceptions out of Spring-LDAP's DistinguishedName class. Spring Security was passing a DN path that was partially quoted like this:
"cn=Pinhead\, Zippy PH/HU,ou=AA,ou=A,ou=Users 135200",dc=dom1,dc=local

I patched DistinguishedName to be able to parse an oddly quoted DN like this, but on further investigation the better place to fix this would be in Spring Security. The JNDI name classes do the quoting, Spring Security should remove them before appending the base.

Am I making sense? I can enter a separate Jira for this if you agree.

@spring-issuemaster

Luke Taylor said:

I think this should be fixed now. The problems were both specific to "/" which is a special character in JNDI names (but not LDAP ones). LDAP escaping of commas etc, should already have been OK, but the "/" can cause problems with lookups and when it is returned froma search (because CompositeName adds quotes to the name). Spring LDAP's DistinguishedName deals with this, but only if the quotes are at the ends of the String, and we were prepending the search base to the DN beforehand.

@spring-issuemaster

Jeff Nadler said:

You da man. I'll grab a snapshot build and test during the upcoming week. Thanks!

@spring-issuemaster

Ulrik Sandberg said:

Well done guys. I'm just curious about something Jeff said earlier about there being more places than BindAuthenticator where the integration with Spring LDAP should be investigated. Should we create another issue for this, perhaps?

@spring-issuemaster

Luke Taylor said:

Hi Ulrik. Which places do you mean? Feel free to send me a mail if you have more ideas.

@spring-issuemaster

Jeff Nadler said:

We're running the 3.0.3 snapshot build now and this issue appears to be completely resolved. Thanks for all the help guys.

Ulrik to be clear I think Luke has nailed it. There were two issues, handling the slash-related quoting 'inbound' and escaping the slash 'outbound'. When I had fixed this myself I did the 'inbound' part by hacking a fix into Spring LDAP so that it's DistinguishedName could parse improperly quoted DNs. That wasn't the proper way to do it of course.

Nothing more to see here. Thanks again all.

@spring-issuemaster

Luke Taylor said:

Thanks for the feedback, Jeff.

@spring-issuemaster

Steffen Ryll said:

Are there any chances that this bug fix will be backported to the 2.0.x series? I'm currently tinkering with this problem in a project where we have Spring 2.5.6 with Spring Security 2.0.4 integrated. We didn't take the migration hurdle to the 3.x series yet, so I'd find it very helpful if this could be fixed in a 2.0.6 release as well.

Thanks for the good work!

@spring-issuemaster

Luke Taylor said:

Hi Steffen. The 2.0.x series is unlikely to see any further releases apart from critical bugfixes now that 3.0 has been released. You can of course apply the patch yourself, or you can get in touch with SpringSource about a commercial support package which might include custom fixes to older versions.

@spring-issuemaster

Steffen Ryll said:

Luke, thanks for the quick response. Luckily, it was not that difficult to back-port that patch to 2.0.5. I just don't like running on non-released libraries, hence my question. Now that I have this patch for 2.0.5: Would you nevertheless be interested to give the patch to the public, for all those who care? Attaching it to this ticket would be the easiest, I suppose?!

@spring-issuemaster

Luke Taylor said:

Sure. If you an attach a minimal patch against the current git 2.0.x branch I will apply it.

@spring-issuemaster

Steffen Ryll said:

Here you go. I had to wrestle with git for a while, but I with good old diff I managed it. The patch is basically equivalent to your patch in 3.x, except that I couldn't prevent my Eclipse from shuffling around the imports. Hope that's ok with you. Thanks again for solving this issue!

@spring-issuemaster

Luke Taylor said:

Ok, thanks. I've applied the patch.

@spring-issuemaster

Anton Khitrenovich said:

Hi Luke,

From the conversation above it is not clear whether this fix was released in some 2.0.x version.I did a quick search in the release notes of 2.0.5 and up and did not find anything related. Please clarify...

Thanks in advance,
Anton.

@spring-issuemaster

Luke Taylor said:

Check the commit log:

$ git checkout 2.0.x
$ git log --pretty=oneline | grep SEC-1444
d6f6a54 SEC-1444: Backport of changes to 2.0.x

or the source tab...

@spring-issuemaster

Anton Khitrenovich said:

Luke,

I'm a user of this project, not a developer.
IMHO, setting up the development environment in order to get answer to this simple question is an overkill.

Please correct me if I'm wrong...

Regards,
Anton.

@spring-issuemaster

Luke Taylor said:

Yes, I think you're wrong :-). And I don't mean that in a bad way. The first thing I do when I have an issue with a third-party project which uses git is clone the source repository. It is a veritable gold mine of information and an essential skill when working with open source.

Of course if you disagree, there is still the "source" tab :-)

@spring-issuemaster

Anton Khitrenovich said:

According to commit history in 2.0.x branch, it should be 2.0.6.RELEASE... Can you please add it to the list of fix versions?

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