CentOS RPM upgrade to 3.9.2 broke LDAP Auth

Openfire Openfire Support
1

I upgraded to 3.9.2 this morning with the official RPM, and when openfire started up users were no longer able to authenticate, nor could i login to the admin panel.

I’m not seeing anything in the error log or warning log, info log has a slew of entries of users clients attempting to authenticate

2014.05.01 09:35:13 org.jivesoftware.openfire.net.SASLAuthentication - User Login Failed. PLAIN authentication failed for:

Steps used to update.

1.) CentOS 6.5, used the RPM (rpm -Uvh fileName.rpm)

2.) ensured saslauthd and openfire were running

3.) attempted to login

Steps used to try and resolve the issue (not in any particular order, didnt document the order!

1.) restarting services (saslauthd and openfire)

2.) verified permissions on all files and directories in /opt/openfire

3.) moved all plugins except admin out of plugins directory

4.) tried replacing the openxml.conf file with a backup

5.) tried replacing the embedded-db with a backup

At this time due to needing this service running have restored a snapshot, but am willing to do testing.

-Chris

2

Chris,

Which version do you have that is currently working? Which JRE vendor and version are you using?

daryl

3

Daryl,

Currently running 3.9.1, using openJDK

rpm -qa |grep -i jdk

java-1.6.0-openjdk-devel-1.6.0.0-3.1.13.1.el6_5.x86_64

java-1.6.0-openjdk-1.6.0.0-3.1.13.1.el6_5.x86_64

4

Thanks, I have no experience with the LDAP machinery in openfire, so hopefully somebody else can chime in. Do you have a test environment to look for log entries related to the failure?

daryl

5

Just an update, I checked the domain controller for failed authentication attempts, and there are no failures. so the auth is either successful, or not reaching the DC.

I restored the 3.9.1 and ldap auth is working again so I dont believe it to be a communications issue with the system.

6

My guess is that openfire is not properly loading the LDAP bits at startup or the internal API is not functioning properly. A log message should have been emmitted at some point with some important details, I hope.

7

I didnt see any errors for it in info,error or warn log :-\

8

Do your users log in with bare usernames or username@domain accounts?

9

user@domain when the account is added, but with things like pidgin it moves the domain to its own field automatically.

10

Hello,

I’ve the same error after upgrade Openfire from 3.9.1 to 3.9.2 today.

uname -r

2.6.32-431.5.1.el6.x86_64

I’m usig Java from the openfire.rpm package.

11

For 3.9.2 we added a feature to encrypt the values of certain properties that are sensitive, including the following:

database.defaultProvider.username

database.defaultProvider.password

ldap.adminDN

ldap.adminPassword

clearspace.uri

clearspace.sharedSecret

You might check conf/openfire.xml to see if these values have been encrypted. If you would like to use the original values in clear text, you may remove the corresponding entries in the conf/security.xml file. Follow these steps:

  1. Stop Openfire
  2. Edit conf/security.xml and remove the ldap.* entries in the encrypted properties list
  3. Restore the original LDAP authentication credentials into the conf/openfire.xml file
  4. Start Openfire

There are additional comments in the security.xml file. Feel free to post back here with your results.

12

I will give this a shot today.

I don’t mean to be rude, but it might be nice to have the updater not touch those settings if you know its going to cause problems, and let people know after the install that the new options exist.

2 Likes
13

Appreciate your offer to help with testing. We don’t intentionally break things, but we are also quite limited in the number of deployment configurations we can reasonably test. As you can imagine, we test relatively few permutations of the several dozen deployment platforms and hundreds of configuration options. When things do occassionally (and inevitably) break, you will be glad to know that we care, and will try to help if we can.

I am not certain that the new encryption feature is affecting you, but wanted to give you a heads-up, just in case.

14

I performed items 1, 2 and 4. And did not touch openfire.xml.

After this server is start work fine.

3 Likes
15

Hi Denis,

OK - thanks for the feedback, glad to know there is a work around.

If you’re willing to test a bit further, it would be helpful to know which of the two LDAP properties (or both) was contributing to the problem you were experiencing:

ldap.adminDN

ldap.adminPassword

If you were to try adding add these properties back into the conf/security.xml file one at a time (with a corresponding stop/start), that would help isolate the root cause of the problem. Ideally we would like to encrypt both of these properties, but I would settle for encrypting the password only if that would work. I can update the core config file to match based on your results.

16

I did the same as Dennis with one additional step and I’m working again.

For me, there is nothing in openfire.xml regarding LDAP. We use the embedded database and all of those values are in the DB. Fortunately, when the server is stopped, you can just edit the openfire.script file to tweak database values. However I still did not need to modify the ldap.adminDN or ldap.adminPassword. They remained in the database in clear text.

My additional step was regarding my LDAP server. We use Active Directory here, so I took a shortcut and just entered the LDAP server as “mydomain.com” which always points to the nearest DC with Windows DNS. However it appears that Openfire 3.9.2 is now also validating the SSL certificate offered by the LDAP server vs. the server name. After updating my LDAP servername in openfire.script to the actual hostname of the site’s DC, everything was fine again.

My question is this: How can we migrate to using the encrypted LDAP properties? If I re-enable the encrypted properties in security.xml, then I can’t get into the server to recreate the values to be stored with encryption. Catch 22. Do I have to change the “setup” value to false and start from the beginning?

17

I found the answer to my question. Once encryption of a property is disabled in security.xml, visit the System properties page. There is a new column of buttons to optionally encrypt each property. Just click the button and it encrypts the property and updates security.xml.

It’s not good to have an update break things like that but one of my commandments is “I shall not complain about free software”.

I should also mention I’m on Ubuntu 14.04 using the .deb package in case that matters.

Jeff

18

Jeff, thanks for your report, very helpful.

I will remove the ldap.* properties from the setup.xml, this should correct the problem for existing installations going forward. I may also add an optional step to encrypt these properties during setup for a new system, which was the original motivation for including them in the default configuration file.

19

Tom, i see the commit. So this will be for the 3.9.3, or should we update 3.9.2 installers again? Maybe we shoul file it as a bug or something, so it won’t be confusing which version encrypts what part of settings.

20

Probably makes sense to update the 3.9.2 build, since this is just a text/config file change. I’ll chat with Daryl about it today and will make a call one way or the other.