I'd like to get Openfire working with TLS 1.2?

I am running Openfire 4.01 on a Windows box. 

If I try to use TLS 1.2 the Spark clients just time out and bad username or password. TLS 1.1 does the same.  TLS 1.0 works fine.

I am observing openfire memleak after upgrading to 3.10.3. When I took a heap dump after taking one single chat (closed the MUC session), I observed that openfire is still holding those xmpp messages belong to that chat. This is confirmed with 2nd chat also (the xmpp messages for both chats are in memory).

This behaviour is very obvious in the server with full load causing memleak in 3 hours.

Are there any configuration missing?

Any one have idea?

Environment:

Openfire 3.10.3

Smack 3.3.0

Using embedded db

Messages that are held in memory are send using following API:

I am facing an issue when Openfire 3.10.3 is used along with smack 3.3.0. However, if I use openfire 3.8.1 with smack 3.3.0, the issue is not seen.

From the heap dump I found that LocalMUCRoom is not getting cleaned up and is held by GroupEventDispatcher. I removed the listener from destroyRoom() function in LocalMUCRoom. Is there any other place we need to remove this listener?

Hello Openfire gurus,

I'm trying to install Openfire 4.1.0 to take advantage of the Stream Management features. I currently have a deployment of 3.11.0 running on an Amazon EC2 instance and connected to a MySQL database (also in AWS). This has been working fine for some months but now the team I'm with wants to upgrade. One wrinkle in the plan is that we have a custom authentication procedure that I have added to the source code. This is working fine in 3.11.0 and requires no special handling for 4.1.0. I just need to get the source (from Github), make the modifications, build the project, and install on my EC2.

I've followed the installation guide here (Openfire: Installation Guide ) and made it to the setup wizard without trouble. I connected the 4.1.0 installation to the same database as 3.11.0. This database has a number of users, chat history, etc etc. Ultimately I want the 4.1.0 installation to use this data, so I connected it to that database. The connection works, and then I go to the admin account setup page. So far this is all stuff I remember from installing 3.11.0.

Then, when setting up the admin account, the wizardnever accepts the 'current' admin password. This renders me unable to set the admin password. The page even says 'If this is a new installation, the current password will be "admin"', a suggestion which doesn't work. I then thought maybe the current password would be the admin password I use in the 3.11.0 deployment - it's not that either. I can choose 'Skip this step' to skip setting the admin password, but then I'm unable to log in to the admin console.

How can I set the admin password? I've done a lot of Googling on this issue and nothing I've found, including rebooting the server and editing the ofUser database table, has worked. Can anyone help me, please?

-- Chris

Log:

at org.jivesoftware.openfire.server.ServerDialback.createOutgoingSession(ServerDia lback.java:253)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:373)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:210)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:266)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:243)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

2016.02.05 07:33:14 org.jivesoftware.openfire.server.ServerDialback[Acting as Originating Server: Create Outgoing Session from: shangryla.net to RS at: 0nl1ne.at (port: 5269)] - An exception occurred while creating outgoing session to remote server:

org.xmlpull.v1.XmlPullParserException: could not determine namespace bound to element prefix stream (position: START_DOCUMENT seen <stream:error>... @1:14)

at org.xmlpull.mxp1.MXParser.parseStartTag(MXParser.java:1816)

at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1479)

at org.jivesoftware.openfire.net.MXParser.nextImpl(MXParser.java:341)

at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)

at org.jivesoftware.openfire.server.ServerDialback.createOutgoingSession(ServerDia lback.java:253)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:373)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:210)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:266)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:243)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

2016.02.05 07:35:43 org.jivesoftware.openfire.server.ServerDialback[Acting as Originating Server: Create Outgoing Session from: shangryla.net to RS at: 0nl1ne.at (port: 5269)] - An exception occurred while creating outgoing session to remote server:

org.xmlpull.v1.XmlPullParserException: could not determine namespace bound to element prefix stream (position: START_DOCUMENT seen <stream:error>... @1:14)

at org.xmlpull.mxp1.MXParser.parseStartTag(MXParser.java:1816)

at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1479)

at org.jivesoftware.openfire.net.MXParser.nextImpl(MXParser.java:341)

at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)

at org.jivesoftware.openfire.server.ServerDialback.createOutgoingSession(ServerDia lback.java:253)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:373)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:210)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:266)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:243)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

2016.02.05 07:38:06 org.jivesoftware.openfire.server.ServerDialback[Acting as Originating Server: Create Outgoing Session from: shangryla.net to RS at: 0nl1ne.at (port: 5269)] - An exception occurred while creating outgoing session to remote server:

org.xmlpull.v1.XmlPullParserException: could not determine namespace bound to element prefix stream (position: START_DOCUMENT seen <stream:error>... @1:14)

at org.xmlpull.mxp1.MXParser.parseStartTag(MXParser.java:1816)

at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1479)

at org.jivesoftware.openfire.net.MXParser.nextImpl(MXParser.java:341)

at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)

at org.jivesoftware.openfire.server.ServerDialback.createOutgoingSession(ServerDia lback.java:253)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:373)

at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:210)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:266)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:243)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

I have version 3.10.2 version of Openfire already installed on my server. Can I install another version let say v4.0.1 ? Can I have two version installed ?

I installed Parrot Bot & Helga bot but it doesn't work...

Copied Bot file in Plugin Folder even i restarted server but these servers aren't coming online on Spark so is there any other bot you know?

We are running open fire in a windows server. Suddenly it stopped responding and the error log has the following error.

org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to error while processing message: <auth mechanism="PLAIN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">AAA=</auth>

java.util.NoSuchElementException

  at java.util.StringTokenizer.nextToken(Unknown Source)

  at org.jivesoftware.openfire.sasl.SaslServerPlainImpl.evaluateResponse(SaslServerP lainImpl.java:114)

  at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java :274)

  at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:179)

  at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:181)

  at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)

  at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

  at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

  at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

  at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)

  at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

  at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

  at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

  at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)

  at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)

  at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

  at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

  at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

  at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)

  at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

  at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)

  at java.lang.Thread.run(Unknown Source)

-------------------------------------------------------------------------------- -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ------

There was one more file in the bin folder of open fire with name 'hs_err_pid1888.log' and the following content was found

#

# There is insufficient memory for the Java Runtime Environment to continue.

# Native memory allocation (malloc) failed to allocate 32756 bytes for ChunkPool::allocate

# Possible reasons:

#   The system is out of physical RAM or swap space

#   In 32 bit mode, the process size limit was hit

# Possible solutions:

#   Reduce memory load on the system

#   Increase physical memory or swap space

#   Check if swap backing store is full

#   Use 64 bit Java on a 64 bit OS

#   Decrease Java heap size (-Xmx/-Xms)

#   Decrease number of Java threads

#   Decrease Java thread stack sizes (-Xss)

#   Set larger code cache with -XX:ReservedCodeCacheSize=

# This output file may be truncated or incomplete.

#

#  Out of Memory Error (allocation.cpp:211), pid=1888, tid=3068

#

# JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)

# Java VM: Java HotSpot(TM) Client VM (24.51-b03 mixed mode windows-x86 )

# Failed to write core dump.

#

---------------  T H R E A D  ---------------

Current thread (0x486bfc00):  VMThread [stack: 0x01ea0000,0x01ef0000] [id=3068]

Stack: [0x01ea0000,0x01ef0000],  sp=0x01eeeb74,  free space=314k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

V  [jvm.dll+0x18e0f1]

V  [jvm.dll+0x1a39a5]

V  [jvm.dll+0x1a4b8b]

C  [MSVCR100.dll+0x5c556]

C  [MSVCR100.dll+0x5c600]

C  [kernel32.dll+0x1338a]

C  [ntdll.dll+0x39f72]

C  [ntdll.dll+0x39f45]

VM_Operation (0x5a14ef28): BulkRevokeBias, mode: safepoint, requested by thread 0x71863400

-------------------------------------------------------------------------------- --------------------------------------------------------------------------------

When this crash happened the server memory was at 30% and cpu usage was negligible and we have set max heap size as '-Xmx1024m' in openfire-service.vmoptions file and we are not specifying min heap size, not sure what has caused this, any help?

Thanks,

Pavan

Hello,

The history: Long time ago there was Openfire 3.9.3 server with SSO working like charm but decision was made to update it to 3.10. After that SSO stopped working even with rollback to 3.9.3, nothing helps. For some time we have to use manual login. After update to 3.10.3 SSO starts working again, to the last week when i have to restart server. It was simple restart, nothing changed but SSO stops again.

What I tried:

• update to 4.0.1
• reset AD account
• new keytab
• DNS tests
• Step by step How to Setup SSO on Windows Server 2008r2/2012r2 with a Domain level of 2008r2/2012r2

Server: Windows Server 2008 R2, Openfire 4.0.1.

Clients: Windows 7-10 Pro, Miranda-NG (Spark only for tests)

Miranda log: <error code="401" type="auth"><not-authorized xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error>

Openfire Info log:org.jivesoftware.openfire.net.SASLAuthentication - User Login Failed. GSS initiate failed

Openfire Debug log:

org.apache.mina.filter.ssl.SslHandler - Unexpected exception from SSLEngine.closeInbound().   javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?    at sun.security.ssl.Alerts.getSSLException(Unknown Source)    at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source)    at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source)    at sun.security.ssl.SSLEngineImpl.closeInbound(Unknown Source)    at org.apache.mina.filter.ssl.SslHandler.destroy(SslHandler.java:204)    at org.apache.mina.filter.ssl.SslFilter.sessionClosed(SslFilter.java:439)    at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:382)    at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:47)    at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:750)    at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:88)    at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:382)    at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireSessionClosed(DefaultIoFilterChain.java:375)    at org.apache.mina.core.service.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:244)    at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:600)    at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:560)    at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$800(AbstractPollingIoProcessor.java:67)    at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1132)    at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)    at java.lang.Thread.run(Unknown Source)      

gss.conf

com.sun.security.jgss.krb5.accept {    com.sun.security.auth.module.Krb5LoginModule required    storeKey=true    keyTab="C:/Program Files (x86)/Openfire/resources/jabber.keytab"    doNotPrompt=true    useKeyTab=true  isInitiator=false    debug=true    realm="DOMAIN.LOCAL    principal="xmpp/server.domain.local@DOMAIN.LOCAL";
};

openfire.xml

[...]  <!-- sasl configuration -->  <sasl>    <!-- Set this to your Keberos realm name which is usually your AD domain name in all caps. -->  </sasl>  <authorization>    <classList>org.jivesoftware.openfire.auth.DefaultAuthorizationPolicy</classList>  </authorization>

krb5.ini

[libdefaults]    default_realm = DOMAIN.LOCAL    default_tkt_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5    default_tgs_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5    permitted_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
[realms]    DOMAIN.LOCAL = {        kdc = dc.domain.local  admin_server = dc.domain.local        default_domain = domain.local    }
[domain_realms]    domain.local = DOMAIN.LOCAL    .domain.local = DOMAIN.LOCAL

Hello,

I have a fresh install Openfire that is integrated with AD thru LDAP. My issue is that the chat rooms that I create are always being deleted automatically not sure why.

Any ideas?

Thanks,

Miguel

Hello everyone. I started this by wanting to use LDAP (Directory Server) to be able to use avatars. There I notice a new version was available so I upgraded from 4.0 to 4.0.1. The problem is I stoped openfire, upgraded, restarted and nothing changed.

I edited conf/openfire.xml and set <setup>true</setup> to <setup>false</setup> to be able to re-run the setuop process and use LDAP and also nothing. I even removed openfire from the server (using Debian 7), confirmed that admin console was offline, reinstalled and still nothing (admin console says version 4 and still no luck with LDAP). It looks like I had two openfire versions installed and all the changes I make are being applied to the version offline, although I know this can't be because I can't have two versions in the same server, am I right?

Any help is appreciated. Thank you.

Is there any guide to secure a openfire installation? Any thing like letting only the essentials/minimalist services/ports running.

hi

service discovery error for change password and email to version openfire 4.0.1

plz chek all

Hi  people

I am not sure whether this a bug of openfire or xabber. Or might be my server troubles only.

However our server has the following issue with xabber to xabber message delivery.

Debug log example:

This is not an issue for xabber to any other im client, only xabber to xabber.

Our server software

Openfire 4.0.1

Debian GNU/Linux 7.9 (wheezy)

java version "1.7.0_95"

OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-1~deb7u1)

OpenJDK Client VM (build 24.95-b01, mixed mode, sharing)

Looking forward for any ideas about what can cause this and how to fix. Also please some advice in further investigation. Thank you.

PS How to remove the links automatic creation?

I've tried to set this up a few times, deleted the files in Program Files. What is the default password? I can't sign in if I skip the step or try to set a new password

Hello,

This is my first time instaling and configuring openfire on linux. I have downloaded from the link http://www.igniterealtime.org/ the Redhat openfire version openfire-4.0.1-1.i386.rpm and run the command rpm -ivh openfire-4.0.1-1.i386.rpm and the installation was done. Afterwards I have renamed mv jre jrexxx the existing jre file under openfire. I have also copied from somwhere the Oracle jdbc library file and the authentication library file to the openfire lib folder. After the restart of the openfire.sh the setup link  worked. I was able to do all setup steps including connection to the database with the database name and password and I skipped the last step in which I could change the default admin user password. Then I was routed to the Openfire admin console page. Here I need to enter an username and password and whatever I try it doesn’t work (username admin and password admin). When I run the install command there was no pop to enter anything it just run. So I never entered or changed any username or password. Could anybody advise please it is very urgent?

Thanks,

B.

I just recently upgraded to OpenFire 4.0.1 on my CentOS server.  I have a Spark 2.7.5 Build 752.  For whatever reason my contact list is empty when my client connects.  Please the attached image. 

Anyone else having this issue?

The error is below.  Not sure what the issue is.

Running on Ubuntu.  Any idea what is going on here.  I did the setup mode reset, so I could at least get to the setup page, but going through the process, and then trying to login again, it still didn't work.

<pre>

HTTP ERROR 500

Problem accessing /index.jsp. Reason:

    Server Error

Caused by:

java.lang.NullPointerException 
at org.jivesoftware.openfire.spi.ConnectionListener.getServerPort(ConnectionListener.java:973) 
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.getPorts(ConnectionManagerImpl.java:891) 
at org.jivesoftware.openfire.spi.XMPPServerInfoImpl.getServerPorts(XMPPServerInfoImpl.java:103) 
at org.jivesoftware.openfire.admin.index_jsp._jspService(index_jsp.java:145) 
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) 
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) 
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669) 
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:1652) 
at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:76) 
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) 
at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:53) 
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) 
at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:80) 
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) 
at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:162) 
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) 
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) 
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) 
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) 
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) 
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) 
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) 
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) 
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) 
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) 
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) 
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) 
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) 
at org.eclipse.jetty.server.Server.handle(Server.java:499) 
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311) 
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) 
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544) 
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) 
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
at java.lang.Thread.run(Thread.java:745) 

</pre>

Configuring Openfire for Use with Kerberos

Openfire server supports single sign-on (SSO) authentication through the Generic Security Services API (GSSAPI). This document is posted in the Enterprise Support section since this is a complex topic aimed at enterprise users. However, this document will work equally well for non-Enterprise license holders. If setting up SSO proves to be too complex, Jive Software offers professional services that can set up SSO in your environment for a reasonable fee. See http://www.jivesoftware.com/support/customps.jsp for more details.

Openfire provides support for GSSAPI and Kerberos, a security protocol in which clients authenticate with a single authentication server, then use that authentic status to request services from other server technologies. Kerberos is invisible to users, of course. When an XMPP chat client such as Spark supports GSSAPI and Kerberos, that support is handled behind the scenes.

This guide assumes you've already set up a working Openfire server, and you have a user and auth provider already working. If you have not already set up Openfire, do so according to the official documentation before you move on. You won't be able to test your Kerberos setup until you've finished setting up Openfire.

Administering Kerberos is a complex subject. This content assumes that you're either experienced with Kerberos administration or are working with someone who is. Unfamiliarity with Kerberos is the single most common reason for errors when configuring Openfire for SSO. For some introductory content on Kerberos, be sure to read the following:

• (along with a )

Vocabulary

There is a lot of vocabulary used in regards to SSO, so Ill try to put them here so there is a clear definition of what is being referred to.

• Authentication - The process of verifying a user really is who the user claims to be.

• Authorization - The process of taking an authenticated user and granting access to particular resources.

• SASL - Simple Authentication and Security Layer. This is the basic protocol used for authentication and authorization in the XMPP protocol.

• SASL Mechanism - Sometimes just referred to as a "Mechanism", this is a particular method of authentication in SASL. Both the client and server need to agree on a mechanism for authentication to be successful.

• Kerberos - The name of the protocol used to authenticate users.

• Token - A special piece of information exchanged between two entities. A token will often have authentication and/or authorization information in it.

• GSSAPI - Generic Security Service Application Program Interface. A generic way of passing tokens between applications. Kerberos is the primary user of GSSAPI, but not the only.

• FQDN - Fully Qualified Domain Name. The DNS name of the server registered to the IP address the server is using.

• Username - This is an overly generic term for the name of a user. With SSO its ambiguous by itself, so whenever possible Ill try to clarify. In general Ill refer to the username as being the Openfire username, though.

• Principal - The term we use for the username of the Kerberos account. Principals can refer to more than just people, however. Takes the form of username@REALM . Note that the username portion of a principal does not need to match the username of Openfire, but it will greatly simplify things if they do.

• Service Principal - Exactly the same thing as a regular principal, but used to denote a service instead of an individual. Takes the form of service/hostname@REALM

• Keytab - A keytab is a special file that contains the "password" for a service principal, or more than one service principal. These files contain sensitive information, so they need to be protected appropriately.

Steps at a High-Level

1. Start with working installations of Kerberos version 5 and Openfire 3.3.0 or later. You can . That way if you need to troubleshoot, you'll already know that the servers are working.

2. . This makes Kerberos aware of Openfire. You'll do this on the KDC host.

3. . This provides a place for Openfire to cache credential information.

4. . Values in this file set the GSSAPI's policy for interacting with Kerberos.

5. . The new values will configure Openfire's support for authentication providers, including Kerberos via the GSSAPI.

6. . Check for the correct amount of network traffic.

7. . Did you miss something?

Verify Your Kerberos Setup

This is slightly different between Unix and Windows, but the main ideas are the same.

• On the system Openfire is installed on, use the {{klist}} command to confirm that the logged in user has a ticket. (klist is native to Unix; for Windows, it's available in the Windows Resource Kit.)

If you don't have a Kerberos realm set up, do that before moving on. On Windows, Windows Active Directory is already using Kerberos; your realm name should be the "Windows Domain Name." When you create a realm, be sure to use all uppercase letters for the realm name. While it's perfectly valid to have a realm with lower case names, and it's not at all typical and Java doesn't handle it well. Additionally, Windows Active Directory has the concept of Local and Domain users. The {{klist}} command will not work for Local users.

Example outputs

Unix

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user@EXAMPLE.COM

Valid starting     Expires            Service principal
06/01/07 15:43:55  06/02/07 01:43:55  krbtgt/EXAMPLE.COM@EXAMPLE.COM        renew until 06/02/07 15:43:53


Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached

Windows

 C:\> klist tgt

 Cached TGT:

ServiceName: krbtgt
TargetName: krbtgt
FullServiceName: user
DomainName: EXAMPLE.COM
TargetDomainName: EXAMPLE.COM
TicketFlags: 0x40e00000
KeyExpirationTime: 0/39/4 0:00:10776
StartTime: 6/1/2007 15:03:03
EndTime: 6/2/2007 1:03:03
RenewUntil: 6/8/2007 15:03:03
TimeSkew: 6/8/2007 15:03:03

Create a Service Principal and Keytab for Openfire

On the KDC host, you will create a principal and keytabe (key table) file for Openfire. You will then transfer the keytab to the Openfire host. The keytab provides a cache for holding credential information used in Kerberos interactions.

The process is different on than on . Windows Active Directory uses Kerberos, by default creating a principal for each user account you create there.

Important! Domain names are very important when using Kerberos. You must make sure that the name of your principal created matches a DNS entry pointing to the same host. If you don't, you're likely to see things break in odd ways. Kerberos uses reverse DNS when it is available, so to determine what name to use for the service principal, use nslookup on the IP address that Openfire will be running on.

$  nslookup jabber.example.com
Server:  ns.example.com
Address:  10.11.12.1

Name:  jabber.example.com
Address:  10.11.12.42
$ nslookup 10.11.12.42
Server ns.example.com
Address: 10.11.12.1

Name:  srv01.example.com
Address:  10.11.12.42

So in this example, the Openfire server on jabber.example.com would use the host name srv01.example.com for the service principal. If this name does not match the "Domain Name" setting in Openfire (the xmpp.domain property), you must set the property xmpp.fqdn to this name as well.

For a KDC Hosted on Unix

If your KDC is hosted on a Unix computer, you can use the kadmin command line to create a principal and keytab file. To do the following, you'll need an admin account in your realm (typically user/admin@REALM.COM). The kadmin command can be run from any host that has proper access to the KDC, and does not need to be run on the KDC itself. If possible, create the keytab file on the host Openfire is installed on so you do not need to transfer the file.

1. Log into the +kadmin+ command.

2. Use the +addprinc+ command to create a new XMPP service principal that is the servername used for Openfire.

The typical command syntax is:

addprinc -randkey xmpp/servername@REALM_NAME

The exact command you use will depend on your realm policy and Kerberos implementation. The server name should be the name discovered using the nslookup command previously. In the following example, jabber.example.com is the server name and EXAMPLE.COM is the realm name:

addprinc -randkey xmpp/jabber.example.com@EXAMPLE.COM

1. Use the ktadd command to create a key table (keytab) file for Openfire. Later, you'll move the keytab to the Openfire host, if applicable, and include its location in your Openfire configuration.

If your Openfire server has a keytab in /etc/krb5.keytab and the Openfire service does not run as root, create a separate keytab file from the host keytab. For example, instead of /etc/krb5.keytab, create the file at /opt/openfire/resources/jabber.keytab. The typical ktadd command syntax for this is:

ktadd -k path/to/file.keytab -e encryption_type:salt xmpp/servername@REALM_NAME.COM

At present, Java can only understand a limited number of encryption types (although Java 6 might support AES encryption for more flexibility), so you might need to make a keytab with a des3-hmac-sha1 encryption type. With this kind of keytab, a ktadd command example could look like this:

ktadd -k /etc/jabber.keytab -e des3-hmac-sha:normal xmpp/jabber.example.com@EXAMPLE.COM

You might also need to download the unlimited strength Java Cryptography Extension (JCE). JCE is subject to U.S. Export Control, however, so be sure to follow the rules for your country.

For a KDC Hosted on Windows

If you have a Windows 2000 or Windows 2003 Active Directory domain already configured, the KDC (Kerberos Key Distribution Center) host service should already be running on your domain controller(s). You will need the setspn.exe and ktpass.exe utilities from the Windows Support and Resource Kit tools installed on your KDC host. Use the links below for your version of Windows 2000.

Windows 2000 SP4 Support Tools

Windows 2000 SP3 Support Tools

Windows 2000 SP2 Support Tools

You will also need the Windows 2000 setspn.exe utility

For Windows 2003 you only need to download and install the Windows 2003 Support Tools which includes both the setspn.exe and ktpass.exe utilities.

1. Log onto your KDC host/Domain Controller using an Domain Administrator account and install the utilities you just downloaded for your version of Windows.


2. Create a new user account with a username/logon name of "xmpp-openfire" and a secure password. The user only needs to be a member of the "Domain Users" group.


3. Enable the account options "Unable to change password", "Password never expires" and "Does not require Kerberos Preauthentication" on the Account tab of the user you just created.

4. Create a Kerberos XMPP SPN for the account you just created using the setspn utility:

setspn -A xmpp/servername.domain.com@REALM.COM xmpp-openfire

Note: "servername.domain.com" should be the fqdn (fully qualified domain name) of your Openfire server. Also, "REALM.COM" should be the name of your Kerberos realm, usually the same as your Windows domain name in all uppercase.

5. Use the ktpass tool to map the Kerberos XMPP SPN to the "xmpp-openfire" username.

ktpass -princ xmpp/servername.domain.com@REALM.COM -mapuser xmpp-openfire@AD_domain.com -pass * -ptype KRB5_NT_PRINCIPAL

Note: "xmpp-openfire@AD_domain.com" is the full AD (Active Directory) username of the account you created above. If you do not put the name of the AD domain that the account was created in on the end, the utility may not be able to find the user account in Active Directory and report an error.

The "-pass *" parameter will tell the ktpass utility to prompt you for the password for the "xmpp-openfire" user account.




Assuming you are running your Openfire server on a Windows server and you have installed the Openfire Server that includes the JRE, follow the next few steps. If you did not use the Openfire Server installation that included the JRE, make sure you are using Java/JRE 6 (1.6.0) or higher.


5. Change directory into the jre\bin folder within your Openfire installation directory or your Java installation directory.

6. Use the Java ktab utility to create your keytab file:

ktab -k xmpp.keytab -a xmpp/servername.domain.com@REALM.COM

Note: The ktab utility will prompt you for the password for the "xmpp-openfire" account you created earlier.

7. The ktab utility should have created a file named "xmpp.keytab" in the current directory. Move this file into the "resources" directory of your Openfire installation directory.

Note: Kerberos is a time-sensitive protocol. Make sure your Openfire server's clock is synchronized with the KDC. Clients are often given a five-minute clock-skew, but it's best if they can be synchronized even closer. Network Time Protocol (NTP) is the most common way of accomplishing this, but other methods may exist. A common problem for Linux based systems is having the timezone incorrectly set, resulting in what appears to be a correct time, that is perhaps several hours off.

Mixing Server Platforms

Kerberos is a platform independent protocol, so your Openfire server may be on a different operating system than your KDC or your clients. If possible, generate the keytab on the Openfire server itself. Since it is not always possible to do this, you may have to transfer the keytab from one host to another. If your KDC is on Windows, then you will need to generate the keytab on a Windows system, such as the KDC itself, then transfer the keytab to the Openfire server. Any Windows system with the proper tools installed should be able to generate the keytab. If your KDC is on Unix, you can generate the keytab on any host that has the kadmin command installed, which should be nearly all Kerberos equipped Unix hosts.

Configure Openfire's Use of GSSAPI

Openfire uses the Generic Security Services API to implement Kerberos support. You'll add values to a configuration file that's used by the GSSAPI. Later, when configuring Openfire itself, you'll add this file's location, along with other Kerberos-related values, to your openfire.xml configuration file.

Note: Windows support requires either a krb5.ini or specifying the realm and KDC on the Java command line.

1. Create a file "gss.conf" in the openfire conf directory.

2. In the file, using the syntax shown below, provide Openfire (using the GSSAPI) with values that are specific your installation

The options include:

• keyTab -- Location of the keytab you created earlier. Note that the directory separator is always a "/" even when on a Windows server (see example).

• realm -- Name of the Kerberos realm that Openfire will be a part of.

• principal -- Name of the principal you created for Openfire.

• debug -- A value specifying whether to log debugging information. Leave it at "true" while setting up, set it to "false" later.

Here's an example of the configuration options and values:

com.sun.security.jgss.accept {    com.sun.security.auth.module.Krb5LoginModule    required    storeKey=true    keyTab="C:/Program Files/Openfire/resources/xmpp.keytab"    doNotPrompt=true    useKeyTab=true    realm="EXAMPLE.COM"    principal="xmpp/jabber.example.com@EXAMPLE.COM"    debug=true;
};

Put this file in the same directory as the openfire.xml is a good idea. For example, you might put it in /opt/openfire/conf/gss.conf.

Its important to leave the rest of this file alone. For complete documentation of this file, go here: http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/LoginConfigFil e.html

Edit Openfire Configuration to Add Kerberos Support

You'll edit the openfire.xml file to configure Openfire so that it has the information it needs to interact with Kerberos via the GSSAPI. In particular, you'll add an two new elements: &lt;sasl&gt; and a new &lt;provider&gt; element.

Add the &lt;sasl&gt; element to create a bridge between the Kerberos system and Openfire. The Simple Authentication and Security Layer (SASL) allows applications like Openfire to preserve loose coupling with authentication mechanisms like Kerberos. The &lt;sasl&gt; element configures that layer to describe which mechanisms Openfire supports and how it supports them.

Here's an example:

<!-- sasl configuration --><sasl>    <!-- Include a comma-separated list of the authentication mechanisms        to advertise support for to clients. Make sure GSSAPI is listed,        and best if it's listed first. The order of mechanisms is important;        clients should try to use the first mechanism they support        (although not all will). Some clients will try to use the most        secure first.        You can add other mechanisms in order to support non-GSSAPI clients,        or clients who cannot authenticate to the realm (like Windows 9X,        off-site, and so on). Keep in mind that by allowing other mechanisms        you are compromising the security of your realm. Be sure to talk        to the Security Officer/Directory/Manager/Administrator about any        policies your organization might have before enabling less secure        mechanisms. By removing PLAIN and ANONYMOUS from the list, you will        also disable non-SASL authentications.        Keep in mind that a mechanism listed here might not actually be        advertised, such as when the authProvider can't support the mechanism.        PLAIN and ANONYMOUS mechanisms also enable non-SASL authentication        (the old style XMPP auth), so removing them from this list will        disallow non-SASL authentication. -->    <mechs>GSSAPI</mechs>    <!-- <mechs>CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS</mechs> -->    <!-- Specify the realm you used when you created the service principal        and keytab.-->    <realm>EXAMPLE.COM</realm>    <!-- Mechanism-specific configuration here -->    <gssapi>        <!-- Use true to turn on debugging information. This adds a lot            of noise to your log files, but it can help you spot problems            sooner in the initial setup. -->        <debug>true</debug>        <!-- Specify the location of the GSSAPI configuration file you edited. -->        <config>/opt/openfire/conf/gss.conf</config>        <!-- Sets the system property with the same name. You'll probably want            "false" here (the default). For more details, see            [http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/package-summary.html] -->        <useSubjectCredsOnly>false</useSubjectCredsOnly>    </gssapi></sasl>

As of Openfire 3.4, the provider section is not needed unless you have special requirements. Leaving the authorization provider out  completely allows Openfire to select the default, which for most will be correct. This section is left here for historical reasons.

Add to the &lt;provider&gt; element to specify classes that provide an authorization mapping between authenticated principals and user names. A comma- or space-separated list is fine here. If you leave this provider out the default will be used, which might be fine for many installations. If you already have a &lt;provider&gt; section, you will just add to the existing one.

Here's an example:

<provider>    <authorization>       <classList>org.jivesoftware.openfire.auth.DefaultAuthorizationPolicy</classList>    </authorization></provider>

The Lazy provider has a different name in the different versions of Openfire, as the logic changes.

The provider names will change again in the future, and will be documented here and in the changelog.

Spark

Configure Spark for SSO usage.

• At the login screen, click on "Advanced" and go to the SSO tab.

• Click on 'Use Single Sign-On via GSSAPI'. If Spark reports what username it will use, this may be all you need to do. If you use Windows, you will need to make an additional change.

If you run Windows, you will need to modify the registry to allow Java to access the credential cache.

On Windows 2000 SP4, Windows 2003 Server and later or Windows Vista:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: AllowTGTSessionKey
Value Type: REG_DWORD
Value: 1

On Windows XP SP2 and later:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos
Value Name: AllowTGTSessionKey
Value Type: REG_DWORD
Value: 1

Older versions of Windows do not need this registry setting.

If Spark was not able to determine a username to use with SSO, you will need to edit some "hidden" properties in the spark.properties file.

The four properties here are:

ssoMethod=string
ssoRealm=string
ssoKDC=string
ssoAdv=boolean

ssoMethod

Set ssoMethod to one of file, dns or manual. If not specified, the default is OS dependent. (On Windows its dns, on others its file)

Set to file to use a krb5.conf or krb5.ini (OS dependent) to determine the realm and KDC information. file is recommended for Unix installations or when a complex realm setup is needed, and DNS is not configured.

Set to dns to use DNS SRV records to determine the KDC information and TXT records to determine the realm. DNS is recommended for ease of administration, but requires additional setup from the default Windows AD DNS records.

Set to manual to use the ssoRealm and ssoKDC fields.

ssoRealm

Set this to the name of the realm to use when ssoMethod is manual.

ssoKDC

Set this to the KDC to use when ssoMethod is manual.

ssoAdv

Set this to true to allow setting the above options on the SSO tab of the advanced settings in the GUI. The default is false.

krb5.con / krb5.ini

If your system requires a krb5.conf (for Unix) or a krb5.ini (for Windows) the syntax is documented below:

[libdefaults]     default_realm = EXAMPLE.COM

[realms]
    EXAMPLE.COM = {        kdc = kdc.example.com        kdc = backupkdc.example.com        admin_server = kdc.example.com        default_domain = example.com    }

[domain_realms]
    example.com = EXAMPLE.COM    .example.com = EXAMPLE.COM

This file should be placed in either /etc/krb5.conf or C:\Windows\krb5.ini or in your OS specific location. For more details on this file syntax, see http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#confdoc

DNS Records

To use DNS records, the following must be set up in your DNS zone:

SRV record

kerberos.udp.example.com Should be a valid SRV record and point to the KDC for your realm.

TXT record

_kerberos.example.com Should be a valid TXT record and contain the name of your Kerberos realm.

Example:

_kerberos._udp.example.com.     7200 IN SRV 0 0 88 kdc.example.com.
_kerberos._udp.example.com.     7200 IN SRV 1 0 88 backupkdc.example.com.
_kerberos.example.com.          7200 IN TXT "EXAMPLE.COM"

Its worth noting that on most operating systems, the hosts file (/etc/hosts or C:\Windows\System32\drivers\etc\HOSTS) will be referenced before DNS. So it is possible to do all of this without DNS; if you use these files, you need to be sure that every client and server share the same information for the server host name and IP address. Managing this is a difficult task for more than a few computers, which is why DNS is preferred, and it is suggested you remove all references to your hostname in /etc/hosts (some OS installs put the host name in the hosts file under the localhost entry, which will break many Kerberos applications).

Multi-homed servers (servers with more than one IP address) are not supported with SSO at this time, but if you know what you are doing it may be possible.

Testing

After all this, you will want to do some testing. A simple Smack program with debugging can show you what is happening at the stream level. You should see the mechanisms being advertised by the server, including GSSAPI. The client should respond with an &lt;auth type="GSSAPI"&gt; packet with lots of base64 stuff in it. Generally, there are going to be six packets exchanged just for authentication; if you see something much different, something went wrong.

Troubleshooting

Common ErrorsCould not load configuration file C:\WINDOWS\krb5.ini (The system cannot find the file specified)

This error occurs when a krb5.ini was not created, and you did not specify via other means the realm and KDC(s) to use. Be sure to read the documentation carefully, and either set up this file or specify the information in other means.

Cannot get kdc for realm EXAMPLE.COM

This occurs when the KDC for the realm is not able to be found. For most people this will mean the krb5.ini or krb5.conf is incomplete or has a typo. However, it could mean that cross-realm authentication is being attempted and there is no knowledge of the other realm.

KDC has no support for encryption type (14)

While this looks like its an encryption type issue, the real problem is Windows is not allowing Java to get the session key from the credential cache. You need to make a modification to the registry to obtain the key.

No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)

This error can occur for a few reasons, most often because of using the wrong service principal name. Double check that your DNS settings are correct, and that the service principal in the keytab matches your DNS.

username@REALM not authorized to username

This means that Kerberos is working correctly, but that authorization failed. Check what you have in your &lt;providers&gt; section of openfire.xml and make sure that you have something listed for &lt;authorization&gt;. What should be listed in this section has changed from version to version. A common problem is having multiple &lt;provider&gt; sections. Openfire will only use one &lt;provider&gt; section, so you need to combine them into one.

Things to check when it goes wrong:

• Does the client have SSO Configured properly? (If the client is Spark, see the Spark Section)

• Can the client run kinit and klist?

• Does Java have the ability to understand the encryption type Kerberos is using in the client credential cache? If not, maybe Java 6 can. Maybe the JCE is needed.

• Does Java have the ability to understand the encryption type Kerberos is using in the server keytab? If not, maybe Java 6 can. Maybe the JCE is needed.

• In Windows 2003 AD when using older versions of Java (some versions of 5, and older), you might need to set the users to "Allow DES encryption for this user".

• You might need to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files (found on the same download page as Java -- but not available in all countries).

• Does the User running Openfire have the ability to read the keytab (is file system permission granted?)?

• Does Java know how to read the Kerberos Credential Cache?

o Windows XP might need to tell older versions of Java that its OS name is "Windows 2000" in order to access the native credential cache (use -Dos.name="Windows 2000" on the java command line).

o Some Unix operating systems might need to force the credential cache to a certain file by setting the environment variable KRB5CCNAME to "/tmp/krb5cc_$UID"

o Java 6 includes the ability to use "Native Kerberos Libraries" on Solaris and Linux, which might help. Read the Java 6 documentation for details on how to do this.

Hello,

I've been using previous versions of Openfire to connect to other Openfire servers as well as to a jabber.org server without any issues. However, once I upgraded from Openfire version 3.10.2 to 4.0.1, I ran into some problems. The two Openfire servers I upgraded were unable to authenticate to the jabber.org server. Under "server sessions", it only showed an incoming session stream from jabber.org, but no outgoing sessions. Here is what the log showed:

2016.02.12 20:11:40 org.jivesoftware.openfire.session.LocalOutgoingServerSession[Create outgoing session for: our-domain.net to jabber.org] - Unable to create a new session: exhausted all options (not trying dialback as a fallback, as server dialback is disabled by configuration.

2016.02.12 20:11:40 org.jivesoftware.openfire.session.LocalOutgoingServerSession[Authenticate local domain: 'our-domain.net' to remote domain: 'jabber.org'] - Unable to authenticate: Fail to create new session.

2016.02.12 20:12:27 org.jivesoftware.openfire.spi.LegacyConnectionAcceptor - Configuration allows for up to 16 threads, although implementation is limited to exactly one.

Here is what  is displayed under "server sessions":

Remote Server Connections Details

Below are details about the sessions with the remote server .

Incoming Session Details

Both Openfire servers are configured to use self-signed certificates. I have the following parameters configured:

xmpp.server.cert.policy = disabled

xmpp.server.certificate.accept-self = true

xmpp.server.certificate.verify = false

xmpp.server.dialback.enabled = false

xmpp.server.tls.enabled = true

xmpp.server.tls.policy = optional

xmpp.socket.ssl.active = true

xmpp.socket.ssl.certificate.accept = true

xmpp.socket.ssl.certificate.verify = false

Cipher suites and protocols are left at their defaults. When I sign into my jabber.org account using Spark, I am unable to see any users on the Openfire servers and they are unable to see me. If I switch back to Openfire version 3.10.2, then bidirectional communication between the Openfire servers and jabber.org works just fine. Clearly, something has changed in the S2S code between those versions. Is anyone else having this issue or is it just me? ;-(

Any help is greatly appreciated. Thank you all!

Michael