Upgrade and lost SSO

Server:

Ubuntu 14.04 64-Bit

Openfire 3.9.3

Java 7u79 (IcedTea 2.5.6)

Database on SQL server.

We are in the process of moving from a VMWare environment to Hyper-V. On Friday night I moved to Openfire server without any issues, and users used Spark on Saturday without issues.

This morning, I did a couple of updates to the server… openjdk-7-jre was included in the list, which I believe brought it to 7u95 or so. I also upgraded Openfire to V4.0.1 right after.

Now, SSO is broken across the board. I have installed the *latest Spark build on my PC (2.7.5) and that has not helped. I can shut down The Hyper-V machine and Start the VMWare machine (still on 3.9.3) and SSO connects fine, so it has to be something on the Server side.

The error I am getting from Spark is:

[Code]

Feb 08, 2016 11:14:24 AM org.jivesoftware.spark.util.log.Log warning

WARNING: Exception in Login:

SASL authentication GSSAPI failed: not-authorized:

[/Code]

This server has been running for about a year and a half, and I have done various updates to it (Such as Openfire and Java updates) without breaking SSO in the past. Since this was a major Version change, is there anything else I need to do to get SSO working?

Thanks.

in java 7u80 and above; java disabled des by default. Most of the SSO guides stated to use DES, so its possible that your keytab file was created with DES only. Recreating your keytab file with a stronger encryption type should fix you up. This should point you in the right direction

How to Setup SSO on Windows Server 2008r2/2012r2 with a Domain level of 2008r2/2012r2

Thanks for the fast response. I’ll give that a shot tonight… Since I have them functional on the VMWare sever, no need to take them down again.

No go… Looking back at my notes, I believe I did -crypto all. However, I decided to attempt to recreate the keytab file anyway… and now both servers (Hyper-V and VMWare) are broken.

I have even now gone as far as creating a new user in AD, creating a new SPN for this user, and another keytab. Attempting to login from Spark then gave me a whole bunch of interesting errors… which were caused by having duplicate SPN’s. Once I removed the duplicates, I am right back to square one:

Feb 08, 2016 8:43:05 PM org.jivesoftware.spark.util.log.Log warning

WARNING: Exception in Login:

SASL authentication GSSAPI failed: not-authorized:

at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java: 342)

at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:243)

at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:1105)

at org.jivesoftware.LoginDialog$LoginPanel.access$1400(LoginDialog.java:333)

at org.jivesoftware.LoginDialog$LoginPanel$4.construct(LoginDialog.java:867)

at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:141)

at java.lang.Thread.run(Unknown Source)

Again, this worked before the updates on the server… so the Server settings and DNS entries should be correct. Any other suggestions?

if you can run wireshark on your workstation, that will provide some clues too. on the user account used for your keytab, make sure you checked “This Account Supports Kerberos AES 128 bit encryption”

I’m not 100% what happened, but it’s working now. Last night I deleted and recreated my gss.conf file and rebooted the server and client machine (this had to be my 8th or 9th reboot), and everything came back up.

Tested again this morning, and I can see all my users have logged in without issues. I must have had something in the gss.conf file that either corrupted or I mistyped at some point, or just didn’t jive with the new Keytab file… at this point it makes no difference, we’re up and running.

This also gave me a chance to clean up some of my prior setup in the process (I didn’t really like the username I used previously), so I’m kind of glad I had to redo it.

Thanks for the advise!

I did have both “This Account Supports Kerberos AES 128 bit encryption” and “This Account Supports Kerberos AES 256 bit encryption” checked.

Last night I did uncheck the AES 256 option, could that of made a difference?

I guess it did… I just enabled it and it broke SSO… disabled it and it works again.

The previous AD user had both enabled also… interesting.

You can use 256 bit encryption, but you’ll need to make sure your have the unlimited strength Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installed on the clients and server, since the default jre only goes up to 128!

Glad you got it up and running!