Openfire LDAP Quotation (encloseDNs) Problem and Fix

Hi everyone,

Some of you may be having issues connecting your Openfire server to your ActiveDirectory or OpenLDAP Server.

The problem I have experienced is that Openfire backslashes characters but also quotes them when sending the query to the directory.

/openfire_src/src/test/java/org/jivesoftware/util/LDAPTest.java

public void testEncloseDN() {
String before = “ou=Jive Software\, Inc,dc=support,dc=jive,dc=com”;
String after = “ou="Jive Software, Inc",dc="support",dc="jive",dc="com"”;

It was possible to add the ldap.encloseDNs = off in the SQL in version 3.5.2, however in 3.6.0/1a Openfire will still send the quotes with the option in the database.

Developers please can you add the option of encloseDN’s On/Off in the Advanced Settings during the installation phase of the LDAP.

For anyone wanting to fix this problem in the mean time, download yourself a copy of the latest source. The file you will need to edit is:

/openfire_src/src/java/org/jivesoftware/openfire/ldap/LdapManager.java

Here is the diff:

~]# diff -c LdapManager.java-UNCHANGED LdapManager.java-CHANGED
*** LdapManager.java-UNCHANGED  2008-11-21 05:31:10.000000000 +1100
--- LdapManager.java-CHANGED    2008-11-21 05:29:49.000000000 +1100
***************
*** 253,259 ****
          }
 
          // are we going to enclose DN values with quotes? (needed when DNs contain non-delimiting commas)
!         encloseDNs = true;
          String encloseStr = properties.get("ldap.encloseDNs");
          if (encloseStr != null) {
              encloseDNs = Boolean.valueOf(encloseStr);
--- 253,259 ----
          }
 
          // are we going to enclose DN values with quotes? (needed when DNs contain non-delimiting commas)
!         encloseDNs = false;
          String encloseStr = properties.get("ldap.encloseDNs");
          if (encloseStr != null) {
              encloseDNs = Boolean.valueOf(encloseStr);
***************
*** 340,351 ****
              followAliasReferrals = Boolean.valueOf(followAliasReferralsStr);
          }
          // the following two properties have been deprecated by ldap.encloseDNs.  keeping around for backwards compatibility
!         encloseUserDN = true;
          String encloseUserStr = properties.get("ldap.encloseUserDN");
          if (encloseUserStr != null) {
              encloseUserDN = Boolean.valueOf(encloseUserStr) || encloseDNs;
          }
!         encloseGroupDN = true;
          String encloseGroupStr = properties.get("ldap.encloseGroupDN");
          if (encloseGroupStr != null) {
              encloseGroupDN = Boolean.valueOf(encloseGroupStr) || encloseDNs;
--- 340,351 ----
              followAliasReferrals = Boolean.valueOf(followAliasReferralsStr);
          }
          // the following two properties have been deprecated by ldap.encloseDNs.  keeping around for backwards compatibility
!         encloseUserDN = false;
          String encloseUserStr = properties.get("ldap.encloseUserDN");
          if (encloseUserStr != null) {
              encloseUserDN = Boolean.valueOf(encloseUserStr) || encloseDNs;
          }
!         encloseGroupDN = false;
          String encloseGroupStr = properties.get("ldap.encloseGroupDN");
          if (encloseGroupStr != null) {
              encloseGroupDN = Boolean.valueOf(encloseGroupStr) || encloseDNs;

I hope this has been usefull for someone as this issue was starting to bug me

This is the problem I am seeing.

Developers, is this fixed in any of the nightly builds yet?

-K

I’m still seeing this problem on 3.6.3 using an Oracle database. Seems like 3.6.3 puts all ldap configs in the database instead of the openfire.xml file. I’ve set both ldap.encloseUserDN and ldap.encloseDNs to false, restarted openfire to reconfigure the install process, and still no luck.

I modified the source as suggested in the original post, and the problem has been resolved. Hopefully this will be fixed or show up as a Advanced setting option in 3.6.4.

Well, better late than never. The issue and workaround are now in our issue tracker. See OF-382 and OF-383. The workaround will be part of the next release (3.7.0).