powered by Jive Software

OpenFire 3.4.x upgrades botch LDAP search filter

Hi All,

It appears that upgrading from OpenFire 3.4.0 to any other 3.4.x release botches the configured LDAP search filter, if the filter contains an ampersand. We’re using this search filter to only display Active Directory users who are enabled (as stored in the openfire.xml file):

(&(sAMAccountName=) (objectClass=user) (! (userAccountControl:1.2.840.113556.1.4.804:=2)) (! (sAMAccountName=$)) )* However, after an upgrade, the line is changed by OpenFire to (as stored in the openfire.xml file): *(&(sAMAccountName=) (objectClass=user) (! (userAccountControl:1.2.840.113556.1.4.804:=2)) (! (sAMAccountName=$)) )

Which is not a valid LDAP search string and returns no users (hence locking everyone including administrators out of OpenFire). This has occurred to us when upgrading from 3.4.0 to 3.4.1, 3.4.1 to 3.4.2 and 3.4.2 to 3.4.3. It took awhile for us to identify what was occuring.

In 3.4.3, if you supply the correct search filter during setup from a clean install, OpenFire still stores the incorrect/mangled version of the search filter.

The non-XML escaped version of the filter is:

(&(sAMAccountName=) (objectClass=user) (! (userAccountControl:1.2.840.113556.1.4.804:=2)) (! (sAMAccountName=$)) )

Any help is greatly appreciated.

Best Regards,

Jason