powered by Jive Software

SSO setup problem using Hazelcast plugin

Hi all,

I have setup 2 Openfire servers as a cluster using the Hazelcast plugin.

Active directory: ad.test.com

First Openfire server: app1.test.com

Second Openfire server: app2.test.com

Common database: db.test.com

Chat client vm: vm1.test.com

I tried the guide at 28 Steps to Single Sign On for Openfire XMPP Server on Windows Server 2012 R2 with Spark and it’s working fine for the first Openfire server at app1.test.com. I can connect using the chat client at vm1.test.com. The debug console at app1.test.com shows that the keytab was used for the login.

The problem comes with trying to configure SSO for the secondary Openfire server at app2.test.com. I created another AD account called xmpp-openfire2 and also used the steps to create a SPN and a keytab for that account. The keytab generated was then copied to the secondary Openfire server resources folder. The gss.conf was also updated to use the principle xmpp/app2.test.com@TEST.COM. However, when trying to connect to app2.test.com using the chat client at vm1.test.com, I am getting warning logs at the chat client that the Kerberos mechanism was not found on the server. The debug console at app2.test.com was also not throwing debug messages even though debug mode was enabled. I am kind of lost on how to enable SSO for the secondary server. Could I get some assistance with this please? I am pretty sure many folks here would want to know as well.

Thanks in advance.

I haven’t tested sso with clustering. I’ll try to set up a cluster after Christmas to test things out. In the mean time, i’d probably start by trying something like this.

use the xmpp domain as the service principal and a single keytab, and then just add the spn for each node to the single keytab.

so for example. if your xmpp domain is EXAMPLE.COM and you have your SRV records resolve to each node, node1.example.com node2.example.com than Id do the following:

setspn -S xmpp/example.com@DOMAIN.LOCAL keytab_user

setspn -S xmpp/example.com keytab_user

setspn -S xmpp/node1.example.com@DOMAIN.LOCAL keytab_user

setspn -S xmpp/node1.example.com keytab_user

setspn -S xmpp/node2.example.com@DOMAIN.LOCAL keytab_user

setspn -S xmpp/node2.example.com keytab_user

then recreate the keytab file with all the spns:

ktpass -princ xmpp/example.com@LOCAL.DOMAIN -mapuser keytab_user@domain.local -crypto all -pass * -ptype KRB5_NT_PRINCIPAL -out xmpp.keytab

then in the gss.conf file, I’d used the setting principal=“xmpp/example.com”

1 Like

after thinking about this…this might not work. I don’t know when I’ll be able to set up a cluster. I was hoping to this week, but it probably wont be for another 2.

Hi Speedy, didn’t reply to this thread after testing this setup, but I managed to got it working. The caveat is there is not enough testing done and I am not sure on the “proper” way to setup either.

I am sharing my configuration, and please correct me if there are suppose to be improvements done.

I created two srv records for _xmpp-client that points to app1.test.com and app2.test.com. I followed the guide 28 Steps to Single Sign On for Openfire XMPP Server on Windows Server 2012 R2 with Spark with some minor alterations.

  • Firstly, the setup to spn at ad.test.com was done using your recommendations. The keytab generated was copied to app1.test.com and app2.test.com Openfire resource folder and the gss.conf file was also updated using your recommendations.

  • I configured the Openfire servers using the Hazelcast plugin installation guide at Hazelcast Clustering Plugin Readme. The Hazelcast config file looked like this: [




Also enabled clustering at both server.

  • Started the Openfire setup using chat server at app1.test.com. The xmpp domain and fqdn were set using test.com instead of app1.test.com.

  • Restarted both chat servers at app1.test.com and app2.test.com and waited for awhile before logging in. Apparently hazelcast plugin takes a long time to load and premature logins causes error at the user group screen. After the chat servers start, they pull the settings from the database at db.test.com

  • I setup the registry settings and copied the krb5.ini to the chat client as usual and restarted to AD user. SSO login was to test.com instead of app1.test.com

These settings work but be aware of the caveats.

Again, feel free to improve on it or use this as a future guide. I hope this facilitates your testing as well.