LDAP-50: BadLdapGrammarException when a group or principal contains a '\' in its name

[rwinch]

Migrated from ["LDAP-50":https://jira.spring.io/browse/LDAP-50]

Hi Guys,

Here is the relevant issue that we have created in Crowd: http://jira.atlassian.com/browse/CWD-183

A quick summary:

If a group contains a '\' we get the following exception: javax.naming.NamingException: problem generating object using object factory [Root exception is org.springframework.ldap.BadLdapGrammarException: Failed to parse DN; nested exception is org.springframework.ldap.support.TokenMgrError: Lexical error at line 1, column 22. Encountered: "\" (92), after : ""]; remaining name 'dc=ad,dc=atlassian,dc=com' at com.sun.jndi.ldap.LdapSearchEnumeration.createItem(LdapSearchEnumeration.java:111) at com.sun.jndi.ldap.LdapNamingEnumeration.nextAux(LdapNamingEnumeration.java:256) at com.sun.jndi.ldap.LdapNamingEnumeration.nextImpl(LdapNamingEnumeration.java:236) at com.sun.jndi.ldap.LdapNamingEnumeration.next(LdapNamingEnumeration.java:184) at org.springframework.ldap.LdapTemplate.search(LdapTemplate.java:271)

If a group contains a '/' we get this exception: org.springframework.ldap.UncategorizedLdapException: Operation failed; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0]; remaining name 'cn=Website Feedback/Support, ou=Groups, dc=ad, dc=atlassian, dc=com' javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-031006CC, problem 5012 (DIR_ERROR), data 0 remaining name 'cn=Website Feedback/Support, ou=Groups, dc=ad, dc=atlassian, dc=com' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3025) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:993) 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_search(ComponentDirContext.java:360) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321) at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248) at org.springframework.ldap.LdapTemplate$4.executeSearch(LdapTemplate.java:227)

If you could shed any light onto this or point us in the right direction we will continue to investigate.

Cheers, Justin

[rwinch]

["Mattias Hellborg Arthursson":https://jira.spring.io/secure/ViewProfile.jspa?name=marthursson] said:

This seems to be the two different problems. In the first case (the one with '\') it seems that Spring LDAP is unable to parse a DN that is returned from the LDAP server. In the other case (the one with '/'), it seems that AD is the one complaining about a DN.

In the first case it would be interesting to know the exact string that is sent to the constructor of DirContextAdapter when the exception occurs.

In the second case, is the DN 'cn=Website Feedback/Support, ou=Groups, dc=ad, dc=atlassian, dc=com'? That should be a syntactially correct DN, however it seems that AD has some problems with forward slashes (http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame3.doc_5.1/am51_adminC_devref359.htm). That might be something to look closer into.

[rwinch]

["Mattias Hellborg Arthursson":https://jira.spring.io/secure/ViewProfile.jspa?name=marthursson] said:

Any more information on this? We're getting pretty close to the 1.2-RC1 release and if this is really a problem in Spring LDAP we should try to sort it out before that.

[rwinch]

["Justin Koke":https://jira.spring.io/secure/ViewProfile.jspa?name=jkoke] said:

Hi Mattias,

I am actually sitting down this morning and working on debugging this further.

Currently it appears to be around escaping the '\' and then escaping it again and again and in the end when the code tries to get the DN it ends up being something like "Website Feedback \\ ".

More to follow while I keep digging.

Cheers, Justin

[rwinch]

["Justin Koke":https://jira.spring.io/secure/ViewProfile.jspa?name=jkoke] said:

Hey Guys,

I am kind of stuck on this one still.

To replicate this problem I am performing the following search:

bc.. // run the search List results = ldapTemplate.search(baseDN, filter.encode(), new DnContextMapper());

p.

bc.. baseDN = java.lang.String = {java.lang.String@31970}"dc=ad,dc=atlassian,dc=com" filter = {org.springframework.ldap.support.filter.AndFilter@38971}"(&(cn=Website Feedback\5cSupport)(objectClass=group))"

p.

So it appears that the '\' is being escaped just fine ... weird.

The underlying execeptions are the following:

bc.. Caused by: org.springframework.ldap.BadLdapGrammarException: Failed to parse DN; nested exception is org.springframework.ldap.support.TokenMgrError: Lexical error at line 1, column 22. Encountered: "\" (92), after : "" at org.springframework.ldap.support.DistinguishedName.parse(DistinguishedName.java:134) at org.springframework.ldap.support.DistinguishedName.(DistinguishedName.java:89) at org.springframework.ldap.support.DirContextAdapter.(DirContextAdapter.java:131) at org.springframework.ldap.support.DefaultDirObjectFactory.getObjectInstance(DefaultDirObjectFactory.java:56) at javax.naming.spi.DirectoryManager.createObjectFromFactories(DirectoryManager.java:218) at javax.naming.spi.DirectoryManager.getObjectInstance(DirectoryManager.java:197) at com.sun.jndi.ldap.LdapSearchEnumeration.createItem(LdapSearchEnumeration.java:105) ... 113 more Caused by: org.springframework.ldap.support.TokenMgrError: Lexical error at line 1, column 22. Encountered: "\" (92), after : "" at org.springframework.ldap.support.DnParserImplTokenManager.getNextToken(DnParserImplTokenManager.java:693) at org.springframework.ldap.support.DnParserImpl.jj_ntk(DnParserImpl.java:253) at org.springframework.ldap.support.DnParserImpl.attributeTypeAndValue(DnParserImpl.java:102) at org.springframework.ldap.support.DnParserImpl.rdn(DnParserImpl.java:62) at org.springframework.ldap.support.DnParserImpl.dn(DnParserImpl.java:27) at org.springframework.ldap.support.DistinguishedName.parse(DistinguishedName.java:130) ... 119 more

p.

So it looks like the JavaCC parser is having an issue. I am not that skilled in the JavaCC space yet, so any insight here would be appreciated :)

Cheers,

Justin

bc..

[rwinch]

["Mattias Hellborg Arthursson":https://jira.spring.io/secure/ViewProfile.jspa?name=marthursson] said:

The DN you get back from the search might very well be formatted differently. It would be very interesting to know the actual String being sent the the DistinguishedName constructor in the stack trace.

[rwinch]

["Justin Koke":https://jira.spring.io/secure/ViewProfile.jspa?name=jkoke] said:

That would be:

bc.. path: java.lang.String = {java.lang.String@30216}"CN=Website Feedback\\Support,OU=Groups,DC=ad,DC=atlassian,DC=com"

p.

There appears to be a few too many escaping '\''s correct?

Justin.

bc..

[rwinch]

["Mattias Hellborg Arthursson":https://jira.spring.io/secure/ViewProfile.jspa?name=marthursson] said:

Am I right to assume that the string is (Java string) escaped (i.e. the actual string as sent to System.out would be @CN=Website Feedback\Support,OU=Groups,DC=ad,DC=atlassian,DC=com@? Then it's not a valid DN, according to RFC1779 (LDAPv2) or RFC2253 (LDAPv3).

We try to be rather strict about the format of supplied DN, which in some cases - like the above example - produces undesired results. It might be possible to hack our way around this, but before we do that we'd need to confirm that this is the general way that AD handles backslashes.

[rwinch]

["Justin Koke":https://jira.spring.io/secure/ViewProfile.jspa?name=jkoke] said:

Yep you are right, regarding the escaping.

From what I can see, when LDAPTemplate performs the search:

bc.. public void search(SearchExecutor se, NameClassPairCallbackHandler handler, DirContextProcessor processor)

p.

The results object that returns has an one value for entries.

The DN of that LDAPEntry is:

bc.. DN: "CN=Website Feedback\Support,OU=Groups,DC=ad,DC=atlassian,DC=com"

p.

So it looks like the '\' is already being doubly escaped at this point.

Then when next() on the entries, the com.sun.jndi lib's get called, and when we get to:

bc.. public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable environment, Attributes attrs) throws Exception

p.

in DefaultDirObjectFactory the name parameter now has been escaped again:

bc.. name: javax.naming.Name = {javax.naming.CompositeName@47328}"CN=Website Feedback\\Support,OU=Groups,DC=ad,DC=atlassian,DC=com"

p.

Is this all making some kind of sense here? Or should I be looking into something else?

So from what I can see SpringLDAP is doing the best it can, but it is just being passed a flakey DN from AD, and it just keeps getting escaped as it makes it way up to the Spring LDAP code.

Justin.

bc..

[rwinch]

["Mattias Hellborg Arthursson":https://jira.spring.io/secure/ViewProfile.jspa?name=marthursson] said:

Hmmm, interesting. The DN you see in the search method is OK - that's java escaped, ldap escaped backslash (LDAP dictates that the backslash be escaped with a backslash and then java escapes both of these leaving us with a total of four backslashes). What intrigues me is that happens in getObjectInstance(). The CompositeName sent to that method is what's screwed up. I'm leaning towards a JDK bug here - could you by any chance put a breakpoint in the CompositeName constructor and check what goes in and what happens in there?

[rwinch]

["Ulrik Sandberg":https://jira.spring.io/secure/ViewProfile.jspa?name=ulsa] said:

Do you by any chance have an AD server with the relevant test data that we can connect to and debug from our site?

[rwinch]

["Ulrik Sandberg":https://jira.spring.io/secure/ViewProfile.jspa?name=ulsa] said:

Not a bug in Spring LDAP, as far as we can determine. Feel free to re-open if you disagree.

[rwinch]

["Mattias Hellborg Arthursson":https://jira.spring.io/secure/ViewProfile.jspa?name=marthursson] said:

Found workaround

[rwinch]

["Mattias Hellborg Arthursson":https://jira.spring.io/secure/ViewProfile.jspa?name=marthursson] said:

see LDAP-109 for details on this.