UPDATE: I tried adding one of my test users to the local administrators group on a laptop; all of a sudden it could no longer log in to Spark using SSO unless elevated. Thus it seems that the user having two tokens causes problems; this explains why it only affects staff members with their own Windows 7 laptop (we grant staff members administrator access to their own personal laptops). I wonder if there’s a group policy security option that could remedy this?
Hi,
We have been using Spark for a couple of years now, without much fuss. However, as we have members of staff that do not have a dedicated desktop or laptop to use and roam from computer to computer, we decided to roll out a combination of SSO and login scripts such that Spark would automatically start and login using SSO on any staff computer for any staff member, without any prior configuration needed from the user or myself.
In general this appears to work beautifully, even a brand new member of staff can log into an arbitrary computer and instantly have a presence on Spark. However, we have started encountering an issue with some of our laptops/users. Specifically, a set of Windows 7 Enterprise x64 laptops. When the owner of this laptop attempts to log in to spark using SSO, they receive the “Unable to connect using SSO error”. The user’s Spark warn.log reports the following:
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Integrity check on decrypted field failed (31))]
- at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(Unknown Source)*
- at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:117)*
- at org.jivesoftware.smack.sasl.SASLGSSAPIMechanism.authenticate(SASLGSSAPIMechanis m.java:86)*
- at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java: 319)*
- at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:203)*
- at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:1014)*
- at org.jivesoftware.LoginDialog$LoginPanel.access$1200(LoginDialog.java:219)*
- at org.jivesoftware.LoginDialog$LoginPanel$4.construct(LoginDialog.java:730)*
- at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:141)*
- at java.lang.Thread.run(Unknown Source)
*Interestingly, if the user is in the local administrators group, and runs Spark elevated it will login using SSO just fine. If a different staff member logs into the laptop, Spark logs in fine, and if the staff member having trouble logs into a different machine it also works fine. Thus why I am laying the blame on the user’s local profile. Allegedly Spark worked fine on Friday 30th for these users, but failed the first thing on Monday. I did consider the possibility that users taking their laptops home and logging in with cached credentials could be causing problems, however one of the users did not even take it home over the weekend.
I have tried completely erasing the user’s Spark folder from their local profile, to no avail. Thus, between the the fact that the issue is localised to a users profile and that elevating to their admin context works, I’m inclined to beleive that there’s something going on with tokens/tickets, perhaps an old invalid cached ticket?. I have tried “klist purge” but that didn’t seem to help.
Thus my question is if anyone has encountered a similar issue and how they managed to resolve it. No doubt clearing the troubled users’ profiles would assist, however I would prefer to know the root cause especially if this is an issue that could develop again on a profile. Note that I’ve been unable to reproduce this error at all outside of the profiles of the handful of users experiencing problems.
For reference, we are running OpenFire 3.7.0 and the clients in question are Spark 2.6.3. We are pushing down the following registry value to the relevant computers and can confirm its presence:
Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value: AllowTGTSessionKey DWORD 1
(The “Parameters” is dropped for Windows Xp clients).
The attached krb5.ini has been pushed to the %SystemRoot% directories of all relevant computers, as well as the server hosting OpenFire. We have configured the following OpenFire properties, and I have attached our gss.conf for reference:
sasl.gssapi.config C:/Program Files (x86)/Openfire/conf/gss.conf
sasl.gssapi.debug true
sasl.gssapi.useSubjectCredsOnly false
sasl.mechs GSSAPI
sasl.realm ST-CLEMENTS.LOCAL
xmpp.domain media-svr01.st-clements.local
Neither our LDAP bind user account nor keytab user is in the domain admins group. The keytab user has “Do not require kerberos pre-authentication” enabled however.
Best wishes,
Karl
gss.conf.zip (363 Bytes)
krb5.ini.zip (333 Bytes)