New job, existing openfire setup - no guides or admin pwds

Hi there.

I’m fairly familiar with XMPP/Jabber, and have setup Openfire/Spark in another organization in the not so distant past. Recently I started at new company, and they have a widely used Openfire/Spark implemenation, but no one in IT seems to know the admin login — as the last admin just up and walked off last fall.

I believe this implementation is using the embedded-db / hsqldb.

I took a look at the contents of the …/embedded-db/openfire.script and grep’d for “admin” and I can see instances of OFUSERS VALUES (with admin.authorizedJIDs), but none of those work, and the passwords are encrypted anyways. I do see a ldap.Admin that points back to an Openfire account sitting in AD (and it shows a password in plaintext) but this doesnt work either.

so I’m wondering:

how do I get into the HSQLDB – especially if I dont have the credentials? I know mysql has some password recovery mechanisms.

is there anyway to get an account added as admin in Openfire? seems like an existing account would have to be added as admin, rather than creating a new one? I saw that you can modify the …/conf/openfire.xml file, but this doesnt look like its even being used… it looks like the default file.

Any help or suggestions is greatly appreciated.


Your options would be to rerun the setup process and set the new password (it won’t delete any user information in the database). To do this stop Openfire and edit /openfire/conf/openfire.xml Change true to false at the bottom.

Or you can add your user with a known password to or (uncommenting those tags first) and he will become an admin next time you start Openfire.

so if I re-run the setup, it wont do anything to the numerous chat rooms setup, the history, user account info, pwds, etc?

but adding a known user, that’s already setup and using the app, to the openfire.xml - within these two tags:


will allow that person to gain admin privs, which can then be used to reset/create any and/or all accounts, create new chat rooms, etc…

seems like the latter is a lot easier than the first – whats best practice here?

I would rerun the setup to get admin user back. Reruning the setup shouldn’t harm your current database, it will just reset admin user, although you should set the same domain name as it is now while doing the setup. Anyway, doing a backup prior any changes is a good practice