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.
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.
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)
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.
If I run Spark on the server it also successfully gets the security principal (ruling out krb5.ini issues)
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.