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.
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.
I didnt see any errors for it in info,error or warn log :-\
Do your users log in with bare usernames or username@domain accounts?
user@domain when the account is added, but with things like pidgin it moves the domain to its own field automatically.
Hello,
I’ve the same error after upgrade Openfire from 3.9.1 to 3.9.2 today.
2.6.32-431.5.1.el6.x86_64
I’m usig Java from the openfire.rpm package.
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:
There are additional comments in the security.xml file. Feel free to post back here with your results.
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.
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.
I performed items 1, 2 and 4. And did not touch openfire.xml.
After this server is start work fine.
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.
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?
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
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.
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.
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.
I am not sure its a good idea to update the builds as it gets confusing as to which build was downloaded by a user. I am also struggling to understand why this bug is happening in the first place. Would it be better to figure out why the bug is happening and squash it, then release 3.9.3 ?
This also did the trick for me.
conf/security.xml
windows server 2012 r2 & windows AD
well done.
This update broke my installation as well. The fix worked.
However, since the installed encrypted the db username and password in the openfire.xml, one can not longer downgrade, as the downgrade doesn’t understand the encryption. I had immediately tried to downgrade when the new version failed.