powered by Jive Software

Spark 2.5.3 SSO + SRV - should it work with Openfire 3.3.0?

The latest version of Spark uses the new Smack libraries. As a result, the when using SRV records to locate the server, the correct security principal is requested from the Openfire server (it used to be wrong in pre-Spark 2.5.3b2).

However, SSO authentication still fails against my Openfire server. It occurred to me that this could be because the server itself is using an old version of Smack. Could anyone confirm whether this is the case?

Our test environment (without SRV records) works well, but for whatever reason the setup is proving more difficult on our production SRV environment.



Ive been busy with my real job lately, so Ive not had time to test with the latest release of Spark. However, Openfire dosnt use smack so if things stopped working it something else.

Do you have any messages from the error logs of openfire (or perhaps spark)?


Am I to understand that you got this to work in some fashion? If so can you provide me with some help? I have a question posted on this as well. I do not know what to do to get this to work.

My config:

Spark 2.5.3 on Windows XP Pro

Openfire 3.3.1 on Windows XP Pro

Accounts in AD on server 2003.

Hmmm, in which case I must have messed up the config.

The client uses the correct principal name, finds it in the directory, then passes it to the server.

The server finds the keytab file, then gives an error about no Kerberos tickets being found.

However, running the java version of klist against the file returns the correct info about the principal in the file.

The config is identical to the dev server which uses the same Active Directory, and as far as I can make the 2 servers are configured identically.

I’‘m tempted to change the XMPP domain and just test it once to see what happens/determine whether this is SRV related. However, I don’‘t really want to take the production system down. I’'ll post some proper logs over the weekend when I next get near the server.


That sounds a lot like a DNS error. If you are using SRV records, then to determind the correct for the principal do this:

lookup jabber domain SRV to get srvname

lookup srvname to get IP

lookup IP to get correct server name

Also, make sure there are no hosts file entries for your server. (And yes, Windows does have this file too)

I thought you didn’'t know anything about Windows?

We don’'t use HOSTS or LMHOSTS files.

DNS checks out (it must, because the client correctly identifies the principal name correctly).

I’‘ll have another look, but I’'m not too optimistic…

DNS checks out OK. Definately no host files.

Logs say:

2007.06.01 22:34:56 SaslException

javax.security.sasl.SaslException: Failure to initialize security context Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)

at com.sun.security.sasl.gsskerb.GssKrb5Server.(Unknown Source)

at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)

… 20 more

If it cant find a key, there are a few reasons it can happen:

It cant find the keytab

It dosnt know what realm its in

It dosnt know what principal to use

It cant use the encryption type of the key

So, what version of Java do you have? Using Java 1.5 requires the JCE to be installed to use the Arc4 (RC4) encryption type, but Java 6 can use it without. Double check that all the openfire.xml points to the correct gss.conf, which points to the correct keytab.

Openfire dosnt use DNS to determine realm and KDC information (yet?), so you either need a krb5.ini/conf or you need to modify the startup.

Make sure all debugging options are turned on

Im sure youve done most of this, but its the one bit you forget or miss that can cause it to fail.

Hmm, what version of Java is being used?

Version 6.

It simply seems like Openfire isn’‘t doing what it’'s supposed to. To recap:

  1. using SRV records for domain.com

  2. xmpp-server looks up to server.domain.com

  3. Spark requests xmpp/server.domain.com@DOMAIN.COM successfully

  4. If I run Spark on the server it also successfully gets the security principal (ruling out krb5.ini issues)

  5. If I change the domain name on the Openfire to server.domain.com everything works ok.

So, I’'m guessing either my DNS is screwy (but then why does Spark correctly identify the correct security principal) OR Openfire iis broken.

My theory is that Openfire (in it’‘s infinite wisdom) attempts to get a TGT for DOMAIN.COM and fails. I’'ve no idea why it even requires a TGT. Surely it should be able can authenticate me without contacting the KDC, or if it has to, use the correct security principal.


With GSSAPI the authentication is two ways. The server also authenticates itself to the client, it just dosnt request any new service tickets to do this, but it does get a TGT in the process.