I am having trouble with SSO for Spark 2.6.3 with OpenFire 3.9.3 that seems to be the opposite of what most people are having:
My Windows 7 machines are working fine, but the Windows XP SP3 machines (I know… I know) are having trouble.
SOME of the XP machines are working fine, but others are not. This seems to be some setting on the XP machines rather than an issues with Spark or OpenFire, or my configurations. I say this because one of the machines that could not log on recently went down for other issues. I re-installed XP and everything else on it, and it connects fine. I’m guessing that somewhere along the lines something got changed on the computer that effects SSO because all of the settings have been applied uniformly across all computers, but only some computers are failing to connect. For the life of me, I haven’t been able to find an answer on Google
What I can confirm about SSO and these problem machines is this:
-AllowTGTSessionKey is REG_DWORD set to 1
-SSO is working over DNS on all other computers without trouble
I’m at a loss, and it’s becoming a problem for the staff. Re-installing windows on every computer isn’t a good idea, either…
If you are using the online version of spark (not bundled with jre), what version of java is installed on the machine? I had an issue where java 1.8 broke sso. Once I removed it, and installed the current 1.7, everything worked again.
Try installing java (1.17.71), and rename the JRE folder thats bundled in spark to something else. see if that works.
Another thing to try is to add the java unlimited strength policy files. This fixed a few random workstation for me, although I have no explanation why.
I installed 1.7.71, copied the JRE into the Spark folder, and renamed so that Spark.exe would look in the newest version. I got an unsupported class version error.
I will try the second suggestion. I just don’t understand why it is only working on half of my computers…
I tried both of these solutions and neither worked. However, I did solve the problem through some random guess and check.
Turns out that a Cisco VPN installed on the machines was interfering with Kerberos authentication. I don’t know why this was happening, although I would guess that the VPN either installed Encryption capabilities that Spark can’t handle (evidenced by the Unsupported encryption type (14) error message) or that the VPN hijacked part of the encryption subsystem. I’m leaning toward the first.
Either way… it’s working!!!
Thank you kindly for your support in troubleshooting this!