Announcement Announcement Module
No announcement yet.
BadLdapGrammarException when Quotes in DN Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • BadLdapGrammarException when Quotes in DN

    There's a similar thread here but I didn't want to wake up a 4 year old topic.

    We're using FilterBasedLdapUserSearch and for some users it's exploding with BadLdapGrammarException. It seems that DnParserImpl can't handle the value that is returned.

    This happens for users with a forward slash in the username. When this forward slash is present the CN gets wrapped in double quotes, and the parser fails on the first double quote character:

    Caused by: org.springframework.ldap.BadLdapGrammarException: Failed to parse DN; nested exception is org.springframework.ldap.core.ParseException: Encountered "\"" at line 1, column 1.
    Was expecting one of:
        <LDAP_OID> ...
        " " ...
    	at org.springframework.ldap.core.DistinguishedName.parse(
    	at org.springframework.ldap.core.DistinguishedName.<init>(
    	at org.springframework.ldap.core.LdapTemplate.executeWithContext(
    	at org.springframework.ldap.core.LdapTemplate.executeReadOnly(

    Anyone got an idea what to do here? Most users can login fine. Unfortunately I can't tell our customer to just change all their usernames to eliminate the slash.



  • #2
    Not sure this is even worth mentioning, but here is a unit test that reproduces the parse exception:

    	public void testQuotedDn() throws Exception {
    		DistinguishedName dn = new DistinguishedName("\"CN=Pinhead\\, Zippy PH/HU\",OU=AA,OU=A,OU=Users 135200,DC=dom1,DC=local");
    		assertEquals("cn", dn.getLdapRdn(0).getKey());
    		assertEquals("Pinhead, Zippy PH/HU", dn.getLdapRdn(0).getValue());


    • #3
      Are you sure that this occurs with Spring LDAP 1.3.0?

      JNDI CompositeName quotes DNs that contain what it believes are illegal characters. This could be such a case. However, since 1.3.0-RC1, we try to detect whether a CompositeName is passed in to our classes and parse it accordingly. See this bug for more info.


      • #4
        Ah, I think I see it now. Spring Security calls the DistinguishedName constructor directly, but the DN is already invalid at that time. The base has been prepended on a quoted name (probably quoted by CompositeName). DistinguishedName can handle a quoted name, but not a quoted and prepended name.


        • #5
          I downloaded the source for 1.3.0.RELEASE, hacked on DistinguishedName.unmangleCompositeName to make it remove the quotes even when they aren't at the beginning and end.

          That got us past the first issue, exposed the next one:

          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(
          	at com.sun.jndi.ldap.LdapCtx.processReturnCode(
          	at com.sun.jndi.ldap.LdapCtx.processReturnCode(
          	at com.sun.jndi.ldap.LdapCtx.c_lookup(
          	at com.sun.jndi.toolkit.ctx.ComponentContext.c_resolveIntermediate_nns(
          	at com.sun.jndi.toolkit.ctx.AtomicContext.c_resolveIntermediate_nns(
          	at com.sun.jndi.toolkit.ctx.ComponentContext.p_resolveIntermediate(
          	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(
          	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(
          	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(
          	... 36 more


          • #6
            ...and solved the next problem, which turns out to be a bug in Spring Security's BindAuthenticator:

            In Spring Security 3.0, line 115 the call to ctx.getAttributes should be using fullDn instead of userDn; by using userDn the encoding in LdapEncoder never gets used.

            Side Note: I learned a lot about the internals of both Spring-LDAP and Spring-Security while hunting this one down. In a few places ( is an example) I found the dividing line between Spring-LDAP and Spring-Security to be less than ideal.

            Maybe a generic BindAuthenticator could live in Spring-LDAP, and a wrapper adapting it to the Spring-Security Authenticator interface could live in Spring-Security. Just a thought.


            • #7
              Yes, it seems the problem is in Spring Security. It would be great if you could create an issue in their JIRA with the patch and other info, such as the places in BindAuthenticator that should be cleaned up.

              We don't consider this a bug in Spring LDAP.


              • #8
                Here's the BindAuthenticator bug:


                There may be another as well, if I end up adding a second Spring-Security bug I will post it here.