Authentication issue for AD users with a slash character in there name

General Discussion
1

I am having an issue importing users from AD that have a slash character ie… " / " in their display name.

This is also mentioned in thread JM-695 but there doesn’t seem to be a resolution for it.

Does any one know of a solution, other than removing the slashes, or plans to fix this?

We are currently using Openfire 3.5.1, not sure if this was looked at for 3.5.2…

2

Slashes are not valid characters for LDAP data. It is an escape character.

3

The escape character is a backslash, \

We are using a forward slash, /

As far as I know the special characters are: “,”, “+”, “”", “”, “<”, “>” or “;”

Are there any logs I should check that will show how the / is being interpreted?

4

The forward slash is a special character that LDAP normally uses for internal purposes, as a separator between certain bits of the LDAP string. That’s why it gets confused if an object name suddenly contains a /

You can try to “escape” it with a \ - so replace your forward slash with a backslash-forward slash combo.

This also applies to a number of other special chars in LDAP, such as comma (,), dot (.), equal sign (=), and a few more as you yourself have mentioned.

5

Here is some info that suggests there is an issue with forward slashes, and the ADSI, http://www.rlmueller.net/CharactersEscaped.htm although my co-workers tell me that we are using other apps making LDAP queries, and not having any difficulties with the / 's.

I changed a forward slash to a backslash, it was escaped by default, and worked.

This should work for a solution, I was hoping I wouldn’t have to remove them all together, you’d be surprised how particular some people are about how there name and title are displayed.

Thanks for all the help, definitely good info.

6

The forward slash is still an issue in our organization. There’s no way it’s going to be changed since we’re an organization of 100,000+ users and the forward slash is used for all contractor accounts.

I’ve verified that it’s the slash causing the problem because I had my AD guy temporarily remove it from displayName and cn on my account.

displayName and

As others have mentioned, we have other apps authenticating against AD that don’t seem to have this problem.

Is there going to be a fix for this? I first asked this about a year ago but got no response: http://www.igniterealtime.org/community/message/152950#152950

Thanks

7

They don’t acknowledge that this is an issue, I still have another open thread, check out:

8

I know OpenFire uses Java… here is a bug report on Sun’s site about slashes in JNDI… not sure if it’s relevant, but it does give more evidence that a forward slash (/) is valid in an AD cn and displayName: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4307193

9

I have posted this before. It right from Microsoft:

http://technet2.microsoft.com/windowsserver/en/library/8196d68e-776a-4bbc-99a6-d 8c19f36ded41033.mspx?mfr=true

Note

•
If the name of a container includes a forward slash character (/), the system requires an escape character in the form of a backslash () to distinguish between forward slashes that separate elements of the canonical name and the forward slash that is part of the container name. For example, if the name of an OU is Promotions/Northeast and the name of the domain is proseware.com, the canonical name is displayed as proseware.com/Promotions/Northeast.

10

Wow, that sucks. There’s no way I’ll convince my organization to make this change. It would need to go to the parent company and go global… I guess Openfire is out for us.

thanks

11

Forgive me because I’m not a Java programmer and I’m not an AD and I’m not an LDAP person…

Why do we authenticate with userDN instead of say, DOMAIN\user ?

For instance, in LdapManager.java, I made the following change (hardcoding my DOMAIN for now):

// env.put(Context.SECURITY_PRINCIPAL, userDN + “,” + baseDN);
env.put(Context.SECURITY_PRINCIPAL, “DOMAIN\” + sAMAccountName);

I passed sAMAccount name into checkAuthentication from LdapAuthProvider.java’s username variable.

It works!

Now what’s the downside to doing it this way?

thanks