powered by Jive Software

The Administration Console hates me

For the second time, I am locked out of the Administration Console. The first time, I was able to use another user to logon. This time, I am not so lucky.

I enabled SSO with out AD - which seems work fine for Spark clients - however, I can no longer login to Openfire Administration. The debug log reports as follows on each logon attempt:

org.jivesoftware.openfire.auth.UnauthorizedException: User ‘me’ not allowed to login.

at org.jivesoftware.openfire.admin.login_jsp._jspService(login_jsp.java:147)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1093)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:42)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:146)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:206)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843 )
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

We are integrated with a SQLServer database. I checked the ofProperty table, and under the admin.authorizedJIDs, there were 3 values, including mine. I removed the other two, just to to be clear. However, I cannot get in.

Is this due to the authentication changes? What are my options for getting access to the Administration Console again? We does it hate me so?

With OUR AD, that is. We are authenticating with our Active Directory…just to be clear…

I’m not really familar with Active Directory or LDAP, just an idea:

If your Active Directory is writeable by Openfire, check this bug in Openfire:

http://www.igniterealtime.org/community/message/190339

=> try to reset your passwords directly in your database and use the openfire.jar provided by Daryl (Iowa State University).

Thanks Coolcat.

I’m able to toy with the user passwords in the database, and the Spark client will respond accordingly. That is, if I disable SSO, and use the normal passwords - I can copy an encrypted password from one user to another, and then logon with that user/password combination to login to Spark.

However, the Admin console still totally hates me. It doesn’t seem to care what user I attempt to logon with, and I’ve tried quite a few - after placing each of the users JID’s in the ofProperty table for the row: admin.authorizedJIDs

I’ve even restarted the service between updates - just to be sure. It’s as if all Admin accounts have been locked out.

Also, I was able to update passwords for users with the method you linked to.

However, it still doesn’t allow me to logon to the Admin console.

Also, I was able to update passwords for users with the method you linked to.
lol, what I wanted to say is that someone else might have used this bug to change all your passwords. If this would be true an attacker might have taken full control over your machine (worst case) and Openfire would simply don’t let you in because your password is wrong.

ah. yeah, no such problem. I only have 4 users created so far…and they can all log into the client just fine.

Well…I found a way to resolve this issue. And I’m a little shocked at the ease of the answer…seems like it would might have been documented somewhere…

Just delete the row for admin.AuthorizedJIDs in the ofProperty table. When that row is missing, I can then log onto the Admin console with no trouble.

Huh.

Thanks for the info. This worked for us too. I noticed once the admin.AuthorizedJIDs propery was deleted, on a restart, it gets recreated as admin.authorizedJIDs - not sure if the case difference is relevant. admin.authorizedJIDs gets populated by a default admin@xmpp.domain account - which gave a clue as to which format the admin.authorizedJIDs should be in - it seems the value(s) of this property must jive with the xmpp.domain.