powered by Jive Software

XMPP Dialback between Openfire/Lync not working as expected

I am trying to establish a S2S comunication between Openfire server and a Lync Server over XMPP. I am using Server Dialback in Openfire Security Settings. The AS (Authoritative Server) is the same as the OS (Originating Server).

The first scenario is the one that works fine, which is when I send a message from Openfire to Lync. You can see the messages exchanged between the two server in the XMPP OF to Lync - OF Forum.pdf that i attached.

The second scenario is the one that doesn’t work as expected because that is an extra … message between the AS and the RS when this two are verifying the Key.

Analysing the XMPP Lync to OF - OF Forum.pdf The problem is that when Openfire sends the verify to the AS (first db:verify with green background in PDF), the next message should be the result from the AS (According to the source code of Openfire), but since Openfire receives a stream (background gray in PDF) from the AS and only after this one the result from the AS, it automatically returns invalid to the OS.

The Lync Server(AS) successfully validates the Key that receives from Openfire (RS) but when the Lync Server sends the valid token the Openfire has already sent to Lync (OS) the invalid token.

My question is: is this a problem of Openfire that can’t handle a stream message between the verification of the Key or is a problem from Lync Server which shouldn’t send the stream (gray background in PDF) ?

Although I am not able to quote an exact protocol specification, I think starttls should either happen before the dialback or after the dialback has succeeded. Seems like a bug of Lync to me.

Lync also includes the key as text for the db:verify element, which shouldn’t cause any problems, but the key as text value does not appear in Example 11 of XEP-0220

See this


Disabling TLS can’t be the (long term) solution. Especially in these times.

Agreed. I upgraded my Openfire 3.8.2 environment to 3.9.3 to try to solve this, without success.

The release notes for 3.9.3 say that this problem is solved, but it is not.

We initially followed the instructions in http://www.globility.co.uk/?p=414, including installing the modified openfire.jar that was supposed to fix the dialback problem. It worked, but given the settings specified was clearly going to result in unencrypted messaging (verified by captures on the network interface).

After the upgrade to 3.9.3 we went through all our testing steps again, trying every variation on Openfire’s server-to-server security settings. The only settings that worked were those in the above-cited article that have TLS set to unavailable (xmpp.server.tls.enabled = false).

Not sure what to do at this point. Any suggestions would be welcome.

You may wish to try the nightly builds as dwd did some more work on this for the next release. Openfire: Project summary - Atlassian Bamboo

Thanks. Plan to test the latest 3.10.0 alpha in my dev environment over the next couple of weeks. Will let you know how it goes.

I know its been a long time, but I just wanted to do an update on our (as yet unsuccessful) efforts to get encrypted server-to-server messaging going between Openfire 3.10.0 Alpha and MS Lync 2013. First, we finally did get fully encrypted s2s between two Openfire servers, one running 3.9.3 and the other 3.10.0. This was with everything completely locked down (TLS mandatory, Dialback not available, etc.). I was then able to (briefly) get a message from a Spark client talking to Openfire out through Lync and to my Lync client. But when I tried to reply Lync barked that “This message was not delivered to mytest@devchat.example.com because the service is not available”. At first I thought that mean that Openfire wasn’t available, but all my Openfire clients were still happily chatting away. Then my partner on the Windows side advised that the Lync XMPP service had crashed. He cranked Lync XMPP back up and we both tried going back and forth a few times with the same results. My network people tell me that their firewalls and load balancers (BigIP LTMs) shouldn’t be causing any issues. Keep in mind that we were successfully able to do messaging and exchange presence info between this same Lync cluster and Openfire 3.9.3 so long as we kept TLS disabled and allowed Dialback. The Openfire logs (including debug) and wireshark traces don’t show anything obviously amiss (in fact they demonstrate successful TLS handshaking and acceptance of messages right up until Lync stops listening). If anyone can think of a reason Openfire might be doing something untoward here to Lync, let me know. Right now my working theory is that this is a Lync problem, but since I’m unable to find evidence that anyone else has ever got encrypted s2s working between Openfire and Lync this is still unchartered territory.

Thank you for the detailed explanation. We are going through the same exercise.

A couple of questions: Did you have to install the modified openfire.jar even after upgrading to 3.9.3

Also, I understand using the nightly build really made no difference as far as federation between Lync and Openfire went? It would still only work without TLS?

Sorry for the late reply.

We didn’t install the modified 3.8.2 jar when we moved up to 3.9.3. We used the jar that came with the later version product.

3.10.0 worked when we turned off TLS and let the servers exchange messages in the clear.