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.
[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.
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.
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.
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
false
false
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.
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.
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:
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.
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”.