Immediately after running the 3.9.3 Openfire update and restarting the Openfire service I found that no one (admins) can now login to the Openfire web console. In my attempt to alter the .xml file to false I found that the setup was erroring out on the last portion of LDAP configuration. I can not even jump ahead to the admin portion. Setting the .xml file back to true allows me to run the Openfire server and users can access and use spark but no console login is possible. Any help is appreciated thank you.
Can you provide additional detail about the error you are seeing during the LDAP setup (screenshot, log message, etc.)? We did make a few changes in that part of the application for this release, so if there is a new problem here we would like to get it resolved quickly.
I can but I would need to shut the openfire server down again causing further disruption to users. We did not orriginally have LDAP setup as we created our user locally in the Openfire server. It was my effort to follow other user suggestions on gaining access by editing the openfire.xml file and changing the true to false then needing no logon but having to go through configuration as if it was a new setup. in the last 2 portions is where I was getting some error screens. Is there no other way to get back in or even downgrade back to 3.9.2?
hi, i am also facing same issue, after installing to 3.9.2 and 3.9.3. even external chat (gtalk and yahoo via openfire) also stopped working, not able to log into console. I have Openfire configured on windows with mysql as db.
Hi there,
since upgrading to 3.9.2 we have the same problem with our openfire server which is using LDAP for user authentication and administration:
How to reproduce:
Add to /etc/openfire/openfire.xml
USERNAME_DNPASSWORD</lda p>
Restart Openfire …
Debug log shows:
host: [ldap.example.com]
port: 636
usernamefield: uid
usernameSuffix:
baseDN: dc=“example”,dc=“com”
alternateBaseDN: null
nameField: cn
emailField: mail
adminDN: USERNAME_DN
adminPassword: PASSWORD
searchFilter: (&(objectClass=inetOrgPerson)(uid=*))
subTreeSearch:true
ldapDebugEnabled: true
sslEnabled: true
startTlsEnabled: false
initialContextFactory: com.sun.jndi.ldap.LdapCtxFactory
connectionPoolEnabled: true
autoFollowReferrals: false
autoFollowAliasReferrals: true
groupNameField: cn
groupMemberField: memberUid
groupDescriptionField: description
posixMode: true
groupSearchFilter: (&(objectClass=posixGroup)(cn=*))
After the restart, /etc/openfire/openfire.xml does not contain
USERNAME_DNPASSWORD</lda p>
anymore
Now database contains:
mysql> select * from ofProperty where name in (‘ldap.adminDN’,‘ldap.adminPassword’);
±-------------------±----------------------------------------+
| name | propValue |
±-------------------±----------------------------------------+
| ldap.adminDN | USERNAME_DN |
| ldap.adminPassword | PASSWORD |
±-------------------±----------------------------------------+
2 rows in set (0.00 sec)
Restart Openfire …
Now debug shows:
host: [ldap.example.com]
port: 636
usernamefield: uid
usernameSuffix:
baseDN: dc=“example”,dc=“com”
alternateBaseDN: null
nameField: cn
emailField: mail
adminDN: null
adminPassword: null
searchFilter: (&(objectClass=inetOrgPerson)(uid=*))
subTreeSearch:true
ldapDebugEnabled: true
sslEnabled: true
startTlsEnabled: false
initialContextFactory: com.sun.jndi.ldap.LdapCtxFactory
connectionPoolEnabled: true
autoFollowReferrals: false
autoFollowAliasReferrals: true
groupNameField: cn
groupMemberField: memberUid
groupDescriptionField: description
posixMode: true
groupSearchFilter: (&(objectClass=posixGroup)(cn=*))
Please note:
adminDN: null
** adminPassword: null**
**
**
This causes anonymous search, which is not working (we require bind & search).
Greetings, Rene
Last night durring non production hours I ran back through the exercise of stopping the openfire service, changing the openfire.xml to false again and then going to the Openfire console to run it through setup. This time I stuck with defaults as it was/is orriginally setup which does get me to the admin account setup. I entered an email and new password clicked continue which brought me back to the Openfire console login. Unfortunatly I am seeing the same results using the USERNAME: admin and new password. I also tried running through it and entering in the current password field admin, along with every variation of possible passwords used. I then tried multiple times logging in using not only the username ADMIN but two other users who had admin rights. One is myself which my spark client logs on as does all other spark users. I can’t add images on here either.
Looks like your property encryption settings have become out of sync. Use the following procedure to fix this issue:
- Stop Openfire
- Check the content of the conf/security.xml file, and remove theses two lines if they exist:
ldap.adminDN
ldap.adminPassword - Start Openfire
I think this should clear things up for you. After Openfire is running, you may manually encrypt the LDAP credentials using the System Properties page in the admin console.
Should I start a new thread again for my issue since I our setup is not using LDAP?
Try this. Stop Openfire, edit openfire.xml and uncomment add admin@yourdomain to this tag, save, start Openfire, try to login as admin.
If you don’t have such tag, add
after the
To add images here, press gray “undefined” link in the top right corner of message editor. It should be saying “Advanced options” but the forums software is bugged.
I did not have the tags so I tried it adding the other tag in as shown below and removing that and adding it after the 1st admin tag but no joy Here is the contents of my openfire.xml file.
<?xml version="1.0" encoding="UTF-8"?>org.jivesoftware.database.EmbeddedConnectionProvider</classN
ame>
net.sourceforge.jtds.jdbc.Driver
jdbc:jtds:sqlserver://m2msql/openfire;appName=jive</serverUR
L>
<username
encrypted=“true”>…
<password
encrypted=“true”>…
select 1
true
true
5
25
1.0
Well, i meant
admin@yourdomain
Also, though it is encrypted, i have deleted passwords from your message.
Ok I tried changing it with the
So is the user name for the openfire server web console now admin@harbingersign.com ? or just admin? Still not getting in.
JID is jabber/xmpp ID, it is how servers and clients operate with users. You should still login with just ‘admin’ into web console. Adding it as JID into authorizedJIDs will make sure that it is tied to the correct domain. Though it should probably work by adding this instead:
admin
So, did it work for you?
Nothing has worked up to this point. Starting to think I need to just start from scratch… So is it
admin
or
admin
that I should try in the openfire.xml and which point as there are two refferences of
Strange hop all users are still able to log on to spark no issue but we as admin can’t log on the the console. If it was not for staff turn over I would be ok. lol
You can use either of them, but a correction:
admin
or
admin**@domain**
There is and then - the closing tag. Haven’t heard about html/xml tags? One should put the above part (any of them) after the closing tag. If you put it in the wrong place, it won’t work. Also, when doing this on Windows 7+, one should run Notepad with Run as admin and then open openfire.xml, because otherwise you will be editing the mirrored openfire.xml which will be stored somewhere C:\Users\wroot\AppData\Local\VirtualStore\Program Files (x86)\Openfire\conf\ and not the real one, so nothing will change (UAC works like that, very confusing stuff from MS…).
Anyway, if you plan to start from a scratch you won’t need anything of this. It should work ok for the fresh setup. These additions only needed when fixing broken setup or changing domain name, etc.
Woot Woot, Wroot!! BACK IN LIKE FLINT!!! Thank you for your very helpful detailed instructions! Yes I have heard of HTML but no I have not worked with it to know how to write it. At any rate we are back in but did have to remember the admin password originally set WAY back WHEN, then had to re add admin rights to the IT group who did have it. Looks like we lost conversation history as well.
May want to work on getting it to authenticate against our AD to ease in new user setups then possibly move this off our RDS to our SQL server anyway to reduce the overhead on the RDS.At any rate thank you for your help again!!!
Hi, I am having the same issue with version 3.9.3. After I get to the final ldap configuration page and press finish, I get the folloing stacktrace:
HTTP ERROR 500
Problem accessing /setup/setup-admin-settings.jsp. Reason:
Server Error
Caused by:
java.lang.NullPointerException
at org.jivesoftware.openfire.admin.setup.setup_002dadmin_002dsettings_jsp._jspService(setup_002dadmin_002dsettings_jsp.java:99)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1359)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:74)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:50)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:78)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:164)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:745)
Is there any fix in sight for the broken LDAP user authentication or shall we downgrade to 3.9.1?