Odd - we did indeed fix the problem that occurred in 3.6.4 in the just-released 3.7.0 beta, but even if you have been experiencing that, that would have been solved by a simple restart of Openfire. You appear to be suffering from another issue. Is there any clue in any of the log files that are generated by Openfire?
Guus, thanks for the speedy response…
No, nothing of value in the logs. In the warn log, all it says is:
Failed admin console login attempt by…
Nothing else in any of the other logs…
**Edit to say: nothing related in any of the other logs. The debug file is blank. Can I turn up logging level somehow?
Running the risk of stating the obvious: did you try ruling out causes other then Openfire itself? Your browser might be caching an old password, your DNS server or hosts file might be pointing you to another instance of Openfire than the one you think you’re connecting to, etc, etc.
Alternatively, could you try to connect to your XMPP domain with an XMPP client? It’d be interesting to see if you can a) create a new user (most clients allow you to do so) and b) use the admin account that you configured to login (the admin account is just another XMPP account).
I have tried connecting from multiple pc’s here on the local lan, clearing browser cache, and I am connecting via the server ip, to avoid any dns issues.
I have not tried connecting with any other clients, but I can try that, I guess.
Want me to give it a try? Is the server publicly accessible?
I wish you could, but it’s behind a firewall…
Try this: shut down Openfire, and open the embedded database file in a text editor (create a backup, just to be sure).
- Add a row that sets the value of the “user.usePlainPassword” property to “true”
- Modify the row in which your admin user is defined, and add a plain text password in the plainPassword column.
Restart Openfire, and try logging in again.
Using Pidgin, I was able to create a new account and login with it… Strange…
Can you login (using pidgin) with the admin account too?
No, it says ‘not authorized’
Something is iffy with the admin account. Odd. Try doing the plaintext-setting and overriding the existing password as I explained above (through the database hack), see if that works. I’m off to bed now - I hope you can resolve this from this point on. If not, leave me a message.
Will do, thank you for your help so far…
as soon as you have an account which can login using Spark you should stop Openfire.
If you have no openfire.log file then you need to edit openfire.script and make sure that there is one line starting with “INSERT INTO OFPROPERTY VALUES(‘admin.authorizedJIDs’,” and which should end with "
" - it should look like this:
INSERT INTO OFPROPERTY VALUES('admin.authorizedJIDs','email@example.com')
If you have an openfire.log file then append there:
DELETE FROM OFPROPERTY WHERE NAME='admin.authorizedJIDs' INSERT INTO OFPROPERTY VALUES('admin.authorizedJIDs','firstname.lastname@example.org')
Of course you need to replace email@example.com with your account. Then start Openfire and you should be able to login with Spark and also into the web console.
I had the same issue because I kept trying to use the email address I used to create the administrator account not realizing that the name I needed to use was “admin”.
I would recommend that on the screen to create the administrator account that it more clearly state that the username is “admin” and not the email address. Though it does say it (“Enter settings for the system administrator account (username of “admin”) below.”), it was easy to skip over quickly and forget later when you login for the first time. I thought I was creating an administrator account that had the username of my email address. Should be more like:
Confirm Password: ______
New Password: ______
That’s an excellent suggestion. I’ll make sure that something along those lines is realized. Thanks!
I’ve added this change as OF-395 in our issue tracker.
Message was edited by: Guus der Kinderen
I do not have an openfire.log, but this line is already there:
INSERT INTO OFPROPERTY VALUES(‘admin.authorizedJIDs’,‘firstname.lastname@example.org,email@example.com’)
INSERT INTO OFPROPERTY VALUES('admin.authorizedJIDs','firstname.lastname@example.org,email@example.com')
I did try logging in with ‘admin’ initially, but got the same results. I tried using the password that I specified, and a blank password to no avail…
To be absolutely clear: in a fresh environment, you should always use the username “admin” and the password that you configured in the admin panel. The e-mail address should not be used.
I uninstalled openfire, rebooted, reinstalled, and was able to logon to the admin console using the ‘admin’ username. I had tried that before, after trying my email address, and it didn’t work, as I said. Not sure if trying my email address caused a problem, I don’t see how it could. The issue must have been caused by something I was doing, but I don’t know what it would have been.
At any rate, thanks to all for the help, I will move on to setup and administration as I continue testing. I’m sure I will be back with more questions as I progress…
Excellent, good to hear that you were able to resolve the issue.
You even consider using your email address as your username is a good argument for Bryans suggested changes. I’ll make sure those are in before we do the 3.7.0 release.