Today I upgraded from 4.2.3 to 4.7 on a ubuntu server using the .deb package. Things seem to have gone fine other than I cannot log into the admin console. I am using ldap for authentication, and if I remember right once I did that prior I no longer had a local admin account. I can still log into spark via ldap. I tried editing the xml file and change the setup to ‘false’ but then I cant get anything to come up. Would appear I have lost the config for users who have admin access rights. Yes I have backups if I need to restore and do something different.
Sorry to hear that, Darren. Let’s see if we can get this resolved.
First of, good on you to have backups. I’m hoping that those include backups of the database that you’re using? If not please create those first and keep them safe somewhere.
The following makes a lot of assumptions on your setup. Your mileage may vary.
In it’s basic configuration, Openfire will retrieve all of its users from LDAP It has a separate configuration that tells it which of these users are administrators.
When you can still log into Spark, then this tells me that Openfire can successfully interact with LDAP. It’s the property that flags certain accounts at admins that seems to be misbehaving.
If you have direct access to the database, then it’s worth checking what the value of that property is. Query the ofProperties table for a row that has a name that equals admin.authorizedJIDs. Those should list (comma-separated) the JIDs (username@domain) of users that are admins. Assuming that these users also exist in LDAP, then these should allow you access to the admin console.
You can overwrite these values by modifying openfire.xml. Inside the <jive> root element, add a <admin> element which then needs to get a authorizedJIDs child element. Add the JID of the user that you want to be an admin to that, then restart Openfire (you can use authorizedUsernames if you want to supply a username, rather than the JID).
<jive>
<admin>
<authorizedJIDs>johndoe@example.org</authorizedJIDs>
<!-- any pre-existing content -->
</admin>
<!-- any pre-existing content -->
</jive>
Upon start, Openfire will move that value from the XML file to the database. That should restore access.
Thank you for your reply, I will give this a shot. I am onboard with your analysis, I do believe it’s the admin flag that was lost.
Here is the code on the local db: INSERT INTO OFPROPERTY VALUES(‘admin.authorizedJIDs’,‘myusername@domain.com’,0)
It still wont work, however as I noted before I can log into the client spark with the same creds just fine
Okay upon further investigation it does not appear to be failing on credentials. When I enter my credentials correctly it just hangs until I hit login again and it comes up with “CSRF Failure!” or it just hangs forever. If I enter my creds wrong it instantly tells me they are wrong. I do require https and the cert I have does not match the hostname. That have something to do with it? I’m just guessing, I have also tried incognito mode and multiple browsers.
CSRF errors indicate that your form-post (that supplies the credentials) does not originate from the login.jsp page. Do you have some kind of redirect setup?
To test the credentials conclusively, try using them to login to Spark (or any other XMPP client).
Have you had a look at the log files? Maybe they contain a clue as to what’s going wrong.
I have it bookmarked, maybe it’s wrong. To clarify the correct url should be “https://ipaddress:9091” is this correct?
Yup. You can use localhost instead of an IP address or hostname if you’re using a browser on the machine on which Openfire is installed. That typically takes away any networking oddities.
As in your example, port 9091 is used for HTTPS. You also have the option of using non-encrypted HTTP on port 9090 (http://yourserver:9090).
I was able to finally get into the admin console. However it was by accident, this time instead of getting impatient and hitting the login button again or refresh, I simply waited it out. At about the 3 min mark it let me in. I can navigate around the console just fine until I try to go back to “Server” then it’s another 2-3 mins before it lets me go there. Any thoughts? Not a timeout issue, spark logs in with my ldap in approx 2-3 seconds. And it’s only the “Server” tab that causes issue. Again this is on a Ubuntu 16.04.7 LTS server build,
Wow! Well, good to see that you’re able to get online - but two to three minutes is way to long, obviously.
Something seems to be timing out. Is there anything in the logs?
I am guessing maybe News section is causing this. You can try setting system property rss.enabled to false and see if there is any difference.