Spark SSO and 64 Bit Windows 7

To start, I will say that our doamin has been running Openfire On a linux server, connecting to a Windows 2003 AD server and SSO enabled XP clients sucessfully for quite some time. We have started testing Windows 7 x64 and I cannot get SSO to work. I have tried:

  • Disabling UAC
  • Adding AllowTGTSessionKey to Kerberos/Paramaters in the registry
  • using the latest SVN version
  • krb5ini, DNS, and manual Realm configuration

I’m not quite sure what to try next. All our XP computers (about 100) are still working just fine with SSO. When I try to log on with one of the Windows 7 comupters, I get the following in the errors log.

WARNING: Exception in Login:
SASL authentication failed:
– caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Integrity check on decrypted field failed (31))]
at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:121)
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:230)
at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:865)
at org.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:200)
at org.jivesoftware.LoginDialog$LoginPanel$1.construct(LoginDialog.java:607)
at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:131)
at java.lang.Thread.run(Unknown Source)
Nested Exception:
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:230)
at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:865)
at org.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:200)
at org.jivesoftware.LoginDialog$LoginPanel$1.construct(LoginDialog.java:607)
at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:131)
at java.lang.Thread.run(Unknown Source)
Caused by: GSSException: No valid credentials provided (Mechanism level: Integrity check on decrypted field failed (31))
at sun.security.jgss.krb5.Krb5Context.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
… 10 more
Caused by: KrbException: Integrity check on decrypted field failed (31)
at sun.security.krb5.KrbTgsRep.(Unknown Source)
at sun.security.krb5.KrbTgsReq.getReply(Unknown Source)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(Unknown Source)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(Unknown Source)
at sun.security.krb5.Credentials.acquireServiceCreds(Unknown Source)
… 13 more
Caused by: KrbException: Identifier doesn’t match expected value (906)
at sun.security.krb5.internal.KDCRep.init(Unknown Source)
at sun.security.krb5.internal.TGSRep.init(Unknown Source)
at sun.security.krb5.internal.TGSRep.(Unknown Source)
… 18 more

Has anyone got SSO working with 64 Bit windows 7?

Run gpedit.msc
Expand “Local Computer Policy” > “Computer Configuration” > “Windows Settings” > “Security Settings” > “Local Policies” > “Security Options” > “Network security: Configure encryption types allowed for Kerberos”
Double click “Network security: Configure encryption types allowed for Kerberos”
Select “DES-CBC-MD5" & "DES-CBC-CRC”

see if that helps.

I have the same issue. I have the settings you’ve suggested but it still does not work.

is SSO working on windows xp?

Yes.

in the policy also enable/check AES256, AES128, and RC4-HMAC long with DES-CBC-MD5 & DES-CBC-CRC.

Reboot and let me know if that helps.

It still does not work.

did you create the following reg key

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos*Parameters*

add DWORD

allowtgtsessionkey

value=1

Yes. I also have the krb5.ini in C:\windows. It is the same configuration as we have on our WinXP computers + your suggestion with the encryption settings.

hmm…maybe a dns issue or a problem with your keytab file? I just did a fresh win 7 x64 install. Without having to do anything other than added the reg key and krb5.ini, sso worked without any problem.

1 Like

I didn’t even have to add the reg key or krb5.ini - I just selected “Use Single Sign-On (SSO) via GSSAPI” on the SSO tab of Spark’s advanced connection preferences. It works great.

This is not working for me either…

Is the domain of my JID’s meant to match my AD domain?

i.e xmpp.domain should be my AD domain?

Have read thorugh every SSO post, but still thouroughly confused!

Here are my notes. I’ve been 100% on getting sso to work in a windows environment.

Make sure the server you are using to host openfire is joined to your domain

Make sure your DNS records are correct, which includes a PTR record

Download and installed windows resource tools and windows support tools

Created your krb5.ini file *note - everything is case sensitive in this file.

Created two AD accounts.
examples

ldap - used for ldap lookups

keytab - used for keytab file and mappings -set password not to expire and user can’t change password.

*Note - all the commands below are case sensitive

WARNING. You can only map this to one user account. If it gets mapped to more than one user, SSO will not work!

Service Princapal Mapping

setspn -A xmpp/fqdn_of_openfire_server@AD-DOMAIN keytab

ktpass -princ xmpp/fqdn_of_openfire_server@AD-DOMAIN -mapuser keytab -pass * -ptype KRB5_NT_PRINCIPAL

*note You will be prompt for a password, use the same password used when you created the “keytab” user account

Create the keytab file

from the /openfire/jre/bin or from /java/jre/bin

ktab -k jabber.keytab -a xmpp/fqdn_of_openfire_server@AD-DOMAIN

Test Jabber.keytab (keytab file)

kinit -k -t jabber.keytab xmpp/fqdn_of_openfire_server@AD-DOMAIN “password”

If nothing is returned and you receive no errors, your keytab file should be good to go.

If you get errors, reset keytab user account’s password in AD using the same password as before and retest

copy japper.keytab to openfire server \Program Files\Openfire\resources

create gss.conf and copy it c:\program files\openfire\conf

Make sure the following are in your openfire system properties

sasl.gssapi.config C:\Program Files\Openfire\conf\gss.conf (location of your gss.conf)

sasl.gssapi.debug false

sasl.gssapi.useSubjectCredsOnly false

sasl.mechs GSSAPI

sasl.realm AD.DOMAIN

xmpp.domain server1.AD.DOMAIN (or whatever your xmpp domain is)

xmpp.fqdn server1.AD.DOMAIN

Copy your krb5.ini to your workstations

Make the required regestry edits.

Same here - SSO works just by enabling. Windows 7 32bit. Spark 2.7 beta. Active Directory on Win Server 2008

Thanks for that!

Will give a shot, maybe ill get it to work before the new year!

Ok awesome, thanks for the kinit ‘test’ suggestion.

My test is failing with the same error I was getting from OpenFire: “Integrity check on decrypted field failed”

Just trying to isolate that issue now

Re-did the ktpass step, and re-did the ktab step.

It works now! But only if I run Spark “As Administrator”

If I dont run spark as admin, I get the error in Spark’s warn.log “GSSException: No valid credentials provided”
(AppData\Roaming\Spark\logs)

Any ideas there?

I never had that problem, but points to a permissions issue with the regular user account. is UAC disabled? if not, try disabling UAC. Do you have the problem when the user is a member of the local computer admin group?

When user IS a local admin, SSO only works when ‘run as admin’

When user is NOT a local admin, SSO does not work either way!!. (‘Run as admin’ is redundant of course)

So now I try with UAC off:

When user IS local admin, SSO works both ways.

When user is NOT local admin, SSO works both ways

Summary:

UAC + Standard user: No go.

UAC + Elevated standard user: No go.

UAC + Privliged user: No go.

UAC + Elevated privliged user: Works.

No UAC, Standard user: Works.

No UAC, Privileged user: Works

I dont get it.

I think its a UAC thing…I guess I never came across this problem because I have to disable UAC on all of our workstations because it causes too many problems with our other applications.