LDAP/ADS Auth blocks WebChat?

I’‘m just doing some initial testing on a 30-day eval of FastPath + Webchat, but I can’‘t seem to get webchat working. Initially I had an issue in that the Jabber domain name didn’'t match DNS, but I worked around that by adding a <serverAddress> chunk in chat-settings.xml. However, the webchat applet now fails after filling in the initial “name / e-mail / question” form, and I get the following in the debug logs:


2006.08.08 13:56:56 Trying to find a user’'s DN based on their username. sAMAccountName: 820e566, Base DN: DC=our,DC=domain,DC=com…

2006.08.08 13:56:56 Creating a DirContext in LdapManager.getContext()…

2006.08.08 13:56:56 Created hashtable with context values, attempting to create context…

2006.08.08 13:56:56 … context created successfully, returning.

2006.08.08 13:56:56 Starting LDAP search…

2006.08.08 13:56:56 … search finished

2006.08.08 13:56:56 User DN based on username ‘‘820e566’’ not found.

2006.08.08 13:56:56 Exception thrown when searching for userDN based on username ‘‘820e566’’

org.jivesoftware.wildfire.user.UserNotFoundException: Username 820e566 not found

at org.jivesoftware.wildfire.ldap.LdapManager.findUserDN(LdapManager.java:511)

at org.jivesoftware.wildfire.ldap.LdapManager.findUserDN(LdapManager.java:439)

at org.jivesoftware.wildfire.ldap.LdapUserProvider.loadUser(LdapUserProvider.java: 69)

at org.jivesoftware.wildfire.user.UserManager.getUser(UserManager.java:171)

at org.jivesoftware.wildfire.user.UserManager.isRegisteredUser(UserManager.java:29 4)

at org.jivesoftware.wildfire.SessionManager.getSession(SessionManager.java:1006)

at org.jivesoftware.wildfire.SessionManager.getSession(SessionManager.java:969)

at org.jivesoftware.wildfire.PresenceRouter.route(PresenceRouter.java:59)

at org.jivesoftware.wildfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:75)

at org.jivesoftware.wildfire.net.SocketReader.processPresence(SocketReader.java:29 6)

at org.jivesoftware.wildfire.net.ClientSocketReader.processPresence(ClientSocketRe ader.java:57)

at org.jivesoftware.wildfire.net.SocketReader.process(SocketReader.java:191)

at org.jivesoftware.wildfire.net.BlockingReadingMode.readStream(BlockingReadingMod e.java:156)

at org.jivesoftware.wildfire.net.BlockingReadingMode.run(BlockingReadingMode.java: 62)

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


It looks like it’'s trying to look up some unique identifying number for the webchat user in LDAP, and then failing, which then kills everything.

I have anonymous logins enabled, and I have permissions set so anyone can create a group chat room. I also tried the “remove all group chat admins” trick mentioned in another thread. None of this has made any difference, unfortunately.

Does anyone have any suggestions on what I should be doing to get this to actually work?

Message was edited by: unit3

Hi,

I have been trying to replicate your problem but cant seem to do it. Here is what I am doing please let me now if you are doing anything different.

  1. Installed Wildfire install 3.0.1 connected to a LDAP user database

  2. Installed Spark Fastpath 3.1

  3. Configured Spark Fastpath with a queue containing several LDAP users

  4. Went to webchat page.

  5. Started a webchat with the group.

  6. Filled out the user info page

  7. Connected to queue

  8. Spark Agent accepted the request

  9. Was able to chat back and forth between.

No errors showed up in the logs. Are you doing something different? Could you please describe your configuration further?

Cheers,

Joel

Yes, this is what I’‘m attempting to do, but I error out after step 6 and before step 7. The only more specific factor is that the LDAP backend we’'re connecting to is an Active Directory server, not OpenLDAP or similar.

I’‘m trying to figure out why it’‘s doing this LDAP lookup for “820e566” and failing, I don’'t really know where that ID is coming from.

Is there a way to externally (ie with Spark or similar) test Anonymous logins and make sure those really are working correctly?

Here’'s some additional config info from the admin webpage:

JVM Version and Vendor: 1.5.0_06 Sun Microsystems Inc. – Java HotSpot™ Server VM

Appserver: Jetty/5.1.x

OS / Hardware: Linux / i386

Locale / Timezone: en / Central Standard Time (-6 GMT)

Java Memory 34.35 MB of 63.31 MB (54.3%) used

This is running on Ubuntu/breezy.

Hi,

I am still working on replicating the problem and have forwarded this post on to our development team for them to take a look at. In the mean time I wanted to verify that you do indeed have a LDAP user with the dn: cn=820e566,dc=our,dc=domain,dc=com

Cheers,

Joel

No, we don’‘t have a user called that at all, which is why I don’‘t know where that search is coming from. It seems to be something that Wildfire or Fastpath has generated. If I knew why it was looking for that (invalid) user, I’'d have a better idea where my config is broken, I think.

Fastpath webchat uses annonymous login names (thats where the weird user id is coming from)… It also uses a groupchat room to communicate…

Make sure you have annonymous logins allowed and also have room creation allowed for all users, and that’'ll probably solve the problem.

Jason

Message was edited by: JayMan

As I mentioned in my first post, anonymous logins are already enabled (although I haven’‘t yet been able to verify that this is actually working because I don’‘t know how to login anonymously using Spark) and anyone can create a group chat room. This doesn’'t solve my problem.

Ah sorry didn’'t see that in the first post…

Hmm i’'ve just tested my setup & the webchat seems to work fine with LDAP here…

Are you running the webchat on the same server as wildfire or a different server? (i’'ve still got it running on the same server as wildfire, havent yet tackled the hurdle of moving it to another server for external access yet)

Jason

I’‘m just running it in 30-day eval mode, webchat on the same server as Wildfire. I’‘m supposed to be showing the eval to management types so they can decide if we want to purchase a handful of licenses for marketing / customer support people, but I can’‘t really do that if I can’'t get the eval working.

I’‘m having an additional problem. I mentioned that I was using in chat-settings.xml to point it to the local host, since the Jabber domain name doesn’‘t match the server’‘s actual domain name. However, it looks like Wildfire periodically overwrites this file (and overwrites it on startup, too), so it doesn’'t keep this setting for more than ~5 minutes.

How can I tell Wildfire about this property, and keep it intact?

I just had another thought on this issue. People who are using fastpathwebchatldap together, are you using something other than Active Directory as your LDAP source? And does your LDAP server allow anonymous binds? Active Directory doesn’'t allow anonymous binds, so maybe this is part of the problem?

Hi unit3,

We’'ve been working with OpenLDAP, but we can try it with AD. Anonymous binds are likely not the problem as that would give definite errors in the logs about being unable to connect to AD.

Regarding the changing serverAddress property, what does it keep reverting to?

Thanks,

Greg

Yeah, I figured it probably wasn’‘t the anonymous bind issues since in the debug logs I’‘m specifically seeing it erroring out looking for non existant (semi-random) account names, presumably ones being generated by webchat. I wish I had some way aside from webchat to test anonymous connections to the server, because it seems like those might not be working even though they’'re enabled.

As for the serverAddress property, it just keeps getting deleted anytime I restart wildfire or restart the webchat plugin. It’‘s like it’'s got the settings for chat-settings.xml stored somewhere else, and it just overwrites that file with its stored versions every time I restart.

I’'m running Fastpath (wildfire enteprise) + webchat + LDAP here without any problems (relating to webchat).

Jason

Jason: what LDAP server are you connecting to? Are you using it for group and vcard information as well?

Hi unit3,

I’‘ve been thinking about this problem and still don’'t have any good ideas. However, I was wondering if you are requiring users to enter their username and password through the webchat form, by any chance? If not, have you made any other configuration changes to the Workgroup or queue?

Thanks,

Greg

No, we’‘re not requiring anything at this point, I’‘m just trying to get anonymous outside people able to connect to webchat and talk to a queue. So far, it’'s been a no-go. The queue itself was created with the default options and the name “test”.

I am doing exactly what you are trying to at my work. One day my manager came and said our one support team would like to be able to “chat” with customers. We were already using AD and wildfire together as an internal solution and so I just add fastpath. So I have AD and FastPath working together.