LDAP with AD not working for most users

Openfire Openfire Support
1

I tried adding onto another thread that seemed to have the same problem. But the guy in that thread ‘‘jaggu’’ never got any replies and eventually claimed he solved the problem without saying what he did to solve it. The thread is marked “Answered” so I fear no one is reading it. So here it is again:

I’‘ve got LDAP authenticating to Active Directory and it works for “generic” accounts. It doesn’'t work for any regular user accounts, (the ones that I actually need it to work for).

It appears to be related to the comma that appears in the Distinguished Name. The generic system accounts which are working do not have “Lastname, Firstname” for the distinguished Name. All my user accounts with the “Lastname, Firstname” DN’'s are failing to log in, even though they are found by the initial LDAP search.

Here’'s my “simple” user, which works:

2006.05.03 16:22:52 Connect Socket[addr=/10.48.128.138,port=2520,localport=5222]

2006.05.03 16:22:52 Trying to find a user’'s DN based on their username. sAMAccountName: ldapbrowser, Base DN: DC=org,DC=company,DC=parentcorp,DC=local…

2006.05.03 16:22:52 Creating a DirContext in LdapManager.getContext()…

2006.05.03 16:22:52 Created hashtable with context values, attempting to create context…

2006.05.03 16:22:52 … context created successfully, returning.

2006.05.03 16:22:52 Starting LDAP search…

2006.05.03 16:22:52 … search finished

2006.05.03 16:22:52 In LdapManager.checkAuthentication(userDN, password), userDN is: CN=ldapbrowser,OU=Org Users…

2006.05.03 16:22:52 Created context values, attempting to create context…

2006.05.03 16:22:52 … context created successfully, returning.

Notice there is no comma in the CN of userDN.

And here’'s a regular user, which fails:

2006.05.03 16:14:54 Connect Socket[addr=/10.48.128.138,port=2442,localport=5222]

2006.05.03 16:14:54 Trying to find a user’'s DN based on their username. sAMAccountName: joshua.parsell, Base DN: DC=org,DC=company,DC=parentcorp,DC=local…

2006.05.03 16:14:54 Creating a DirContext in LdapManager.getContext()…

2006.05.03 16:14:54 Created hashtable with context values, attempting to create context…

2006.05.03 16:14:54 … context created successfully, returning.

2006.05.03 16:14:54 Starting LDAP search…

2006.05.03 16:14:54 … search finished

2006.05.03 16:14:54 In LdapManager.checkAuthentication(userDN, password), userDN is: “CN=Parsell, Joshua (AJ-East Engineering/Technology),OU=Org Users”…

2006.05.03 16:14:54 Created context values, attempting to create context…

2006.05.03 16:14:54 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)

at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)

at com.sun.jndi.ldap.LdapCtx.(Unknown Source)

at org.jivesoftware.wildfire.ldap.LdapManager.checkAuthentication(LdapManager.java :335)

at org.jivesoftware.wildfire.ldap.LdapAuthProvider.authenticate(LdapAuthProvider.j ava:9 0)

at org.jivesoftware.wildfire.auth.AuthFactory.authenticate(AuthFactory.java:114)

at org.jivesoftware.wildfire.net.SASLAuthentication.doPlainAuthentication(SASLAuth entic ation.java:284)

at org.jivesoftware.wildfire.net.SASLAuthentication.doHandshake(SASLAuthentication .java :144)

at org.jivesoftware.wildfire.net.SocketReader.authenticateClient(SocketReader.java :317)

at org.jivesoftware.wildfire.net.SocketReader.readStream(SocketReader.java:278)

at org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:119)

at java.lang.Thread.run(Unknown Source)

Notice there is a comma in the CN of the userDN, and the whole userDN is in double quotes, unlike the userDN for the “simple” user.

Also, I found this by Google:

http://www.codecomments.com/archive408-2005-5-499111.html

Quote: “Duh - some genius (Not I! I do unix) put a backslash in my DN ( CN=Burris, Celeste Suliin) I needed to double it to get the DN to LDAP correctly.”

Any help? Any suggestions? Can I fix this by changing my wildfire.xml or is this something that requires a software update?

I am running Wilfire Server 2.6.2 on RHEL 4. My LDAP server is Active Directory 2003.

Message was edited by: parseljc

2

I don’'t speak Java. But I do speak other programming languages. Looking at the LdapManager.java code, I see these lines (Wildfire 2.6.2) in the checkAuthentication method:

314 env.put(Context.SECURITY_AUTHENTICATION, “simple”);

315 env.put(Context.SECURITY_PRINCIPAL, userDN + “,” + baseDN);

316 env.put(Context.SECURITY_CREDENTIALS, password);

As I pointed out above, the userDN is already in double quotes for my regular users, because of the “Lastname, Firstname” syntax we have set up in Active Directory.

So the difference in what is being passed to Active Directory is this:

ldapbrowser: CN=ldapbrowser,OU=Org Users,DC=org,DC=company,DC=parentcorp,DC=local

Joshua.Parsell: “CN=Parsell, Joshua (AJ-East Engineering/Technology),OU=Org Users”,DC=org,DC=company,DC=parentcorp,DC=local

That’‘s got to be the problem… Anyone have a quick solution? Or should I pull out my “SAMS Teach Yourself Java 2” and figure it out? Seems to me we need to get rid of the double quote on the end of the userDN, append the comma and the base DN, and then append the double quote again. Or, get rid of the double quotes altogether. The comma in the CN is already backslash-escaped coming out of Active Directory, so I don’'t know if the double quotes are even needed, unless AD puts them there because of all the spaces?

3

How about changing:

314 env.put(Context.SECURITY_AUTHENTICATION, “simple”);

315 env.put(Context.SECURITY_PRINCIPAL, userDN + “,” + baseDN);

316 env.put(Context.SECURITY_CREDENTIALS, password);

to:

env.put(Context.SECURITY_AUTHENTICATION, “simple”);

if (userDN.endsWith(""")) {

userDN = userDN.substring(0, userDN.lastIndexOf(""") - 1);

env.put(Context.SECURITY_PRINCIPAL, userDN + “,” + baseDN + “”");

else {

env.put(Context.SECURITY_PRINCIPAL, userDN + “,” + baseDN);

}

env.put(Context.SECURITY_CREDENTIALS, password);

Would that work? Same type of fix needed around line 358 for alternateBaseDN.

4

Okay 2 weeks and not a single reply. I can only conclude that I have uncovered a bug in Wildfire and there is no way to get around it with the current version.

If that’'s the case, how do I report this bug so the developers can try to fix it in a future release?

5

Since our AD userNames are the same as yours cn=“Lastname, Firstname” , your “bug” is exactly the same issue we had for quite some time. This is why we use this method of authenication with our Wildfire/clients:

Using the sAMAccountName has worked well for us. This is also how our users must login to their Outlook webmail.

Hope this helps!

Bob

6

Finally a response! 8-O

I am using the same configuration in my wildfire.xml,

so that is not the solution. There must be something else different about your configuration or your AD entries. Regardless of what you use for usernameField or nameField, the LDAP still has to verify uniqueness in the directory, and I believe it does that by matching the distinguishedName. The problem is that when you have a comma in the displayName, it comes out to what Wildfire calls userDN enclosed in double quotes. The Wildfire Java code I showed above tacks on a comma and the baseDN, but that fails to match the distinguishedName because of the double quotes. Something else must be different about your set up if you have it working. Could I trouble you to turn on debugging and post the debug log section from where one of your “Lastname, Firstname” users are logging in? Then we could compare it to what mine is doing to see what’'s different.

7

DOH!

It’‘s not the comma. It’'s the forward slash. (See the

(AJ-East Engineering/Technology)

^^^^

in my userDN in the debug info above?)

So anyways, everything I’‘ve stated about the quotes around the userDN breaking the match and stopping the login is true. It’‘s just not the comma causing the double quotes. I played around with my simple user, adding the comma and the parentheses to his distinguished name trying to break his login. It didn’'t break (and start double-quoting the userDN in the debug log) until I added a forward slash / to his displayName.

SO THIS IS A REAL BUG. It’‘s just not related to the comma. It’'s related to forward slashes. Which cause double quotes around userDN. Which breaks the match and the login process.

8

Hi,

you can track the issue here: JM-695

LG

9

Thanks!

10

Hey guys,

Users whose CN has commas can log in just fine. As you noticed the problem is with forward slashes being used as DNs of users or groups. After reading some documentation about AD I found the following information that might be useful:

Although users and groups can be created with names that use a distinguished name string that contain a forward slash character, subsequent operations on the object might fail. Some Active Directory functions interpret the forward slash character as a separator between the object name and the host name. To avoid the problem, do not use a forward slash character to define the user.

So based on that information I would recommend not using forward slashes in DNs.

Regards,

– Gato

11

Gaston,

The comma is a problem. It is reproducibly and verifiably the cause of presence problems. So don’'t give up on that one yet! You still need to resolve why having a comma in userDN causes presence updates not to work. When I removed the commas from a couple of test users I no longer had presence problems.

Can you point us to the source of your information on AD and forward slashes. I can tell you that we have a large number of AD users with forward slashes in their usernames and have never had any “subsequent operations on the object” fail. If Microsoft did not allow forward slashes, why does it even let me use them when I create the user? Not saying I don’‘t believe you, but it would be nice if you could point us to a (hopefully Microsoft) website that says, authoritatively, "Don’'t use forward slash in AD." Otherwise, how am I supposed to convince the AD admins at my company to go back and remove all the forward slashes from AD? I am not the AD admin here.

Thanks for your attention to this matter so far.

-Josh

P.S. - the new site design is cool, but the forum posting screen IS HORRIBLE!!! IT’'S JUMPING ALL OVER THE PLACE WHILE I TYPE AND I AM ABOUT TO HAVE A SEIZURE TRYING TO LOOK AT IT!! WHAT IS GOING ON?! I am using MSIE 6.0.

Seriously, with every single character I type, the scroll bar on the right in my edit window disappears and reappears, causing the whole screen to jump twice, as the line wraps all change because of the brief increase in window width when the scroll bar disappears. I am having to stare at my keyboard to type instead of looking at the screen, because it’'s giving me a headache and I think I might puke. Somebody please fix this ASAP.

12

Hey Josh,

CNs with commas are now working fine. The bug fix is available in the next nightly build or you can just grab it from SVN and build wildfire with ant. Regarding the reference sources of the forward slash I found these 2 links from a quick search:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm. itame.doc/am60_adminc_devref377.htm (last paragraph)

http://www.tokeshi.com/index.php?name=News&file=article&sid=381

Regards,

– Gato

13

In my previous post I was saying that users whose CN has a comma are able to log in. The issue we fixed is related to the presence problem. So the problem logging in is affected by the forward slash.

Regards,

– Gato

14

Thanks, Gaston. How soon until the comma bug fix is included in a “stable” release? By “next nightly build” do you mean I should come back tomorrow and then get the 2006-07-12 build?

I will point my AD admins to the information you’‘ve supplied. Since it doesn’‘t come from Microsoft, it seems iffy that they will be willing to make wholesale changes to our entire Active Directory, but I can ask. Is it really not possible to fix this on the Wildfire side? Still seems to me that the goal should be to make it work with any Active Directory user that Active Directory itself allows to be created, rather than telling people "remove the forward slashes in AD if you have them, because there’‘s lots of software that doesn’'t work with AD when it has forward slashes, including Wildfire."

-Josh

15

Hey Josh,

How soon until the comma bug fix is included in a “stable” release? By “next nightly build” do you mean I should come back tomorrow and then get the 2006-07-12 build?

That is correct. BTW, Wildfire 3.0.1 will be out this Thursday that will include this fix. I’'m trying to fix every reported LDAP issue for the next release.

I will point my AD admins to the information you’‘ve supplied. Since it doesn’‘t come from Microsoft, it seems iffy that they will be willing to make wholesale changes to our entire Active Directory, but I can ask. Is it really not possible to fix this on the Wildfire side? Still seems to me that the goal should be to make it work with any Active Directory user that Active Directory itself allows to be created, rather than telling people "remove the forward slashes in AD if you have them, because there’‘s lots of software that doesn’'t work with AD when it has forward slashes, including Wildfire."

Agreed. Believe when I say that we tried to find a workaround to this problem. My concern though is that the workaround may not work with other LDAP servers so the cure may be worst than the initial problem. Having said that, I don’‘t consider this case closed. I’'m still looking for a good regular expression that will help me identify the cases that we need to enclose in " like we did for the comma issue. FYI, all LDAP issues that where reported seem to be triggered when some special characters are used. And not all LDAP servers behave in the same way or are 100% compliant.

Regards,

– Gato

16

Okay, great! I’'ll just wait till Monday maybe and try 3.0.1.

I understand what you’'re saying about difficulty in trying to make the LDAP work for AD as well as all other LDAP servers. Thanks for your help!

-Josh

17

Hey Josh,

In the next nightly build you will find a potential fix to the forward slash. I will hopefully be able to test it tomorrow but I can say that it has not break current functionalities.

Regards,

– Gato

18

I just got 3.0.1 installed and the comma no longer creates a presence problem. Thanks!

Forward slash still prevents login, however. (I wasn’'t sure whether the fix you said was in the next nightly build was going to be included in 3.0.1?)

Since the comma was fixed in 3.0.1 for JM-695, but the forward slash is still an issue, should a separate bug report be created for the forward slash so we can track what version that will be fixed in?

Thanks again,

-Josh