powered by Jive Software

Openfire 3.6.0a upgrade and LDAP

We’ve currently got Openfire 3.5.2 installed and working perfectly fine with our LDAP server. (Which is a Penrose LDAP server proxing back to our Active Directories server)

I upgraded to 3.6.0a and started getting errors when trying to connect to the LDAP server, so thinking the problem might be the upgrade I’ve done a fresh install but still no luck. From our LDAP server logs I can see the problem is related to Openfire enclosing the admin user name in quotes.

Working… Openfire 3.5.2

[17/Sep/2008:11:57:35 +0100] BIND conn=10121 op=0 msgID=1 type=SIMPLE dn=“uid=admin,ou=system”
[17/Sep/2008:11:57:35 +0100] BIND conn=10121 op=0 msgID=1 result=“Success” message=“Success” authDN=“uid=admin,ou=system” etime=1

Failing… Openfire 3.6.0a

[17/Sep/2008:11:57:38 +0100] BIND conn=10122 op=0 msgID=1 type=SIMPLE **dn=“uid=“admin”,ou=“system””
**[17/Sep/2008:11:57:38 +0100] BIND conn=10122 op=0 msgID=1 result=“Invalid Credentials” authFailureID=196826 authFailureReason=“Unable to bind to the Directory Server as user uid=admin,ou=system because no such user exists in the server” etime=0

Is there a way to turn this off I’ve found post about people using the system properties ldap.encloseDNs and ldap.encloseUserDN but I’m still having the same problem.



I use Lotus Domino LDAP service.

In 3.5.2 and above there was a parameter in .cnf called “ldap.encloseUserDN”. When set to false all worked fine. But now it is ignored by 3.6.0 thus it was copied to MySQL table called opproperty.

Here is a log part:

-> localhost:389

0000: 30 81 86 02 01 02 63 3F 04 09 6F 3D 22 41 6D 74 0…c?..o="Amt
0010: 65 6C 22 0A 01 02 0A 01 00 02 01 00 02 01 00 01 el"
0020: 01 00 A0 1C 87 03 75 69 64 A3 15 04 0B 6F 62 6A …uid…obj
0030: 65 63 74 43 6C 61 73 73 04 06 70 65 72 73 6F 6E ectClass…person
0040: 30 05 04 03 75 69 64 A0 40 30 23 04 16 31 2E 32 0…uid.@0#…1.2
0050: 2E 38 34 30 2E 31 31 33 35 35 36 2E 31 2E 34 2E .840.113556.1.4.
0060: 34 37 33 04 09 30 07 30 05 04 03 75 69 64 30 19 473…0.0…uid0.
0070: 04 17 32 2E 31 36 2E 38 34 30 2E 31 2E 31 31 33 …2.16.840.1.113
0080: 37 33 30 2E 33 2E 34 2E 32 730.3.4.2

<- localhost:389

0000: 30 0C 02 01 02 65 07 0A 01 20 04 00 04 00 0…e… …

Any ideas from Dev team?

fixed by ldap.encloseDNs=false

In my MySQL database table ofProperty I have “ldap.encloseDNs=false” and “ldap.encloseUserDN=false” but still see the same problem with the username being enclosed by quotes.



Even after the addition of the ldap.encloseDNs=false the debug of the LDAP connection still looks wrong.


0000: 30 2B 02 01 01 60 26 02 01 03 04 17 75 69 64 3D 0+…`&…uid=
0010: 22 61 64 6D 69 6E 22 2C 6F 75 3D 22 73 79 73 74 “admin”,ou=“syst
0020: 65 6D 22 80 08 43 72 65 74 34 74 30 6E em”…password


0000: 30 0C 02 01 01 61 07 0A 01 31 04 00 04 00 0…a…1…

javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]



Are you sure that you have 3.6.0a?

Seems like the setup web page is broken for openfire 3.6.0a with regards to Lotus Domino LDAP integration. You might have more luck simply editing openfire.xml or populating ofProperty table manually.

What I did to get it working was :

  • installed openfire 3.5.2

  • setup via web, make sure to use MySQL (easier this way). Setup completes, but I can’t login via admin interface yet.

  • stop openfire

  • edit openfire.xml, add



to section

  • start openfire

  • login to web admin console to verify it’s now working.

  • upgrade to 3.6.2 (with rpm -Uvh)

  • login to web admin console (again) to verify it’s still working

I ended up with a working 3.6.0a that integrates to Lotus LDAP, almost empty openfire.xml, and table ofProperty now populated with entries (including all ldap settings) that used to be in openfire.xml.

I suspect you could also get it working by creating the appropriate openfire.xml or ofProperty manually from scratch.

It should be 3.6.0a and I’ve just checked the change log and its got the changes for this version.


Still having the same problem, I’ve been able to setup the software to talk to another LDAP server but still can get it to stop passing quotes. I’ve got both ldap.encloseDNs and ldap.encloseUserDN set to false but this doesn’t seem to effect the user DN. I don’t have access to this other LDAP server from the really install so this isn’t an option.

I’ll try installing 3.5.2 again and then upgrading to 3.6.0a but this was what I tried initially and it failed.


I’ve noticed that it only enclose it in quotes if theres a “=” in the UserDN it doesn’t have a problem with “admin@system” or similar but my LDAP server only supports the “uid=admin,ou=system” version.

OK its a bug in the install/configure LDAP properties, worked fine when I’d set the encloseDNs’/encloseUserDNs before I upgraded from 3.5.2 to 3.6.0a. I’m still unable to use the admin page to test and make changes but they work fine outwith this.

So this problem only exist for clean install might be worth having these options in the Advanced settings during the LDAP configuration.

Thanks for the help guys.


Hi fajar,

I am currently facing the same problem with the unix version.

Can you share how you actually do it ? Like what are the settings in DB ?

Thanks in advance


a patch to this problem (notes-specifc, simply disables encloseDNs hardcoded in LdapManager.java, instead of hard-codedly enabling them) and some group problems described here are fixed for 3.6.4 by this patch:

http://blog.f4k3.net/fake/index.php/post/2009/08/31/openfire-3.6-and-lotus-domin o/notes-ldap

in case you wonder: yes, the above thread about lotus domino / notes and groups is from me, too. my previous forums account was disabled for some secret reason and the contact sheet on jive software (the only contact possibility i found) seems to be ignored. neither has anyone ever commented on the patch. i was unable to submit the patch to the bug tracking system as it is closed for outsiders - i didn’t want it to be included in it’s current state, it’s a hack - i’d just like to hear opinions.

while the license may be somewhat open-ish, the development process is not. this calls for a fork


Sorry to hear that your development experience with Openfire hasn’t been pleasant thus far. If you have a Jira account, I can get you necessary privledges to create tickets and attach patches. have you submitted a developers agreement to Jive?

Yes, opening up this entire process is something a number of us are working on.


hi daryl,

ah, that would be helpful my jira account name is “fake” (that one has not been removed/block), i signed up back when i created the first thread, and was pretty confused about not even being able to create bug reports.

what developer’s agreement? here you go: “I won’t do bad things. scribble”.


If you could send in this form, you will be all set: