Wildfire 3.1.0B2 Possible Problem with LDAP

Openfire Openfire Support
1

Hi All,

I am having a problem with 3.1.0B2 and LDAP. When I use the same settings on a stable release, users can authenticate without any issue from the LDAP server. In 3.1.0B2 however, when I enable the LDAP section in wildfire.xml, I can’'t log in, eirther as an admin or as a user. A tcpdump shows the packets going across to the LDAP server, but authentication seems to fail somewhere on the wildfire side. I have posted the xml details below for ldap.

Is this a bug or I am doing something wrong.

Thanks in advance

AJ

Plaform: Suse 10.1

Version: 3.1.0. Beta 2

LDAP Server: Edirectory

Wildfire.xml

2

Do you have a section added like this in your conf file:

<admin>

<authorizedUsernames>** Put your admin account names here, comma delims for more then one **</authorizedUsernames>

</admin>

3

Hi Wvankuyk,

Yes I have my own LDAP account in as the admin name. However all usernames of registered LDAP users fail. Thus no Spark user can login as the get invalid username or password warnings.

The weird thing, is if I use the stable release, they have no issue in logging in. Just in 3.1.0B2.

AJ

4

Ahh sorry, I miss read your post the first time around. I haven’'t started using the beta, and maybe I will hold off upgrading until we get this resolved. Interesting…

5

Just to update on this. I ran an Ethereal session while I tried to authtenticate a user using the SPark client agains Wildfire server.

It appears that the server is not sending the proper request to the server. It sends the cn=admin, but not the o=test, it shoudl be sending cn=admin,o=test for the bind request to return a vailid connection.

I think this maybe a bug, has anyone else tried this? Or can the verify this?

Thanks

AJ

6

In order to get this to work with Edirectory (Although I imagine with any other LDAP V3 compliant server), you will have to change the following line in your wildfire.xml

Then the request to bind is sucessful and wildfire will work again. If anyone else can verify that this may be a bug that would be great, then I’'ll file a bug report.

Thanks

AJ

7

After reviewing my config, I did specify the fully qualified DN path for the Ldap Admin account. The DN is always a full path, by definition, so this is not a bug, however if the intention was for an RDN or Relative Distinguished Name, then yes we have a bug here.

In short, its supposed to have the whole string in there, and the baseDN is to add on to user logon requests.

This is the RFC for DN’'s for all of those who are curious:

http://www.rfc-editor.org/rfc/rfc2253.txt

8

Not a bug

Not a documentation issue

Just a pitfall for users who have little experience with LDAP or did never use LDAP before

continued in Wildefire 3.1.0 Beta 2 sends incorrect bind information and thus this thread may be locked.