BUG: AD integration can't deal with slash in OU name

Openfire Openfire Dev
1

Troubleshooting a user who could neither log in and didn’t appear in the ‘Users’ list, when I enabled the debug log I saw this:

2009.09.07 14:47:29 LdapManager: In LdapManager.checkAuthentication(userDN, password), userDN is: “CN=“Leanne Caines”,OU=“Affiliate/Corporate”,OU=“Users”,OU=“Affiliate Network”,OU=“Business Departments””…
2009.09.07 14:47:29 LdapManager: Created context values, attempting to create context…
2009.09.07 14:47:29 LdapManager: Caught a naming exception when creating InitialContext
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece�]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)

She was the only person in that OU, and it’s the only OU which contains a forward slash… so on a hunch that this was a parsing bug, I renamed “Affiliate/Corporate” to “Affiliate and Corporate” (I didn’t dare try an ampersand…) using Windows ADUC and the user could immediately log in.

We’re running Openfire 3.6.4 on Windows.

Cheers,

Gavin.

2

slashes will need to be escaped or not used at all.

3

Yep, I worked that out and have resolved the problem as described in my post. The point I’m making is that this behaviour is surely non-obvious and ripe for better parsing code to avoid confusion by new users?

4

ONe could say it is a parsing issue, but one could argue that it was the use of an invalid character in the name as well. When configuring LDAP servers it is better to stick to alphanumeric characters, dashes and underscores. No spaces or special characters because it can cause problems or slowness with queries. Just because windows is dumb enough to let you use the characters does nto mean you should.

5

Certainly any argument can be made - I think only from usability aspect rather than technical / compliance. If non-alpha chars are considered harmful, can they at least be detected and marked in the ‘Info’ log so as to make it obvious to the user (i.e. so they don’t have to enable the high-verbosity Debug log) ?