powered by Jive Software

SSO Worked then died

I went through the Wiki SSO doc on setting up Openfire/Spark SSO on a Windows 2k3 server. Everything went fine and it worked right off the back for about 20 minutes. Then boom, no more worky. Nothing showing in the logs and I still have the debug option enabled. When I enable debugging on the openfire server I am still not seeing any output pertaining to SSO. Nothing happened in between this time either. I was merely going around the office showing every then, of course, when I went to show my boss it crapped out.

Any ideas?



First, lets dismiss the idea that nothing happened, since something obviously did (Im not saying its your fault, though) Lets try to figure out what is going on.

Make sure you check all the logs on the server. There is a start.out/start.err (or something like that) that can show SSO information.

If nothing is showing up in the logs on the server, check the logs on the client. Something to keep in mind with Kerberos is your tickets have designated lifetimes and can expire. Windows should renew the tickets when you unlock a locked workstation, but who knows. If you have the resource kit installed, check “klist.exe tgt” to see the expiration information.

Next, you might check if the client is able to contact the server at all. Try without SSO and make sure that still works (assuming you didnt disable all non-SSO login methods)

Thanks for the quick response slushpuppie!

I really have no idea what changed because honestly I was just walking around showing people how it works and no one else has access to the server, oh well, maybe just a fluke that it was working anyway.

Apparently I hadn’'t searched well enough :confused:


Found this thread that you had helped someone with earlier. I got as far as being able to get the server to start reporting stuff (the Spark client is just reporting the SASL auth error).

Now I am seemingly getting this from Openfire:

Key for the principal xmpp/jabber.xxx.com@xxx.COM not available in C:/Program Files/Openfire/resources/jabber.keytab

authentication failed

Unable to obtain password from user

The error about being unable to obtain a password means that your gss.conf is likely incorrect- can you post it?

com.sun.security.jgss.accept {




keyTab=“C:/Program Files/Openfire/resources/jabber.keytab”







Message was edited by: LAMEtHIng

Can you check the keytab file? Make sure that it is still in C:\Program Files\Openfire\resources\jabber.keytab and is readable by the user running Openfire (and preferably no one else). Also, what command did you use to create the keytab file?

It is there and the permissions are set.

I just checked the Spark logs again and they have changed…(wth??) …now I am getting this:

javax.security.sasl.SaslException: GSS initiate failed Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7))

klist tgt is showing proper output, also.

Its starting to look like you have an incorrect principal name in the keytab.

You need to make sure the principal name is correct in the keytab. What was the command you ran to generate the keytab file?

ktpass -princ xmpp/jabber.xxx.com@XXX.COM -mapuser xmpp-jabber.xxx.com -pass password -out jabber.keytab

Ok, now lets make sure that you have the right name.

Get the ip address of your server, and run “nslookup ipaddress” The name returned from that is what you should be using.

Think I might’'ve found the problem. Get back to you in a sec.

Thanks for all the help SP.

Acquire TGT using AS Exchange

authentication failed

KDC has no support for encryption type (14)

From openfire now, I believe that is new.

Was the exact keytab generation and the nslookup resolves to the ptldme-mngt.xxx.com

C:>ktpass -princ xmpp/ptldme-mngt.xxx.com@xxx.com -mapuser xmpp/ptldm

e-mngt.xxx.com -pass password -out jabber.keytab

That error means you did not set the registry key on the client.

Hmm, I did though. :confused:

Double check- and make sure you have the right one for the OS.

For Windows 2003 and Windows 2000 SP4:


Value Name: allowtgtsessionkey

Value Type: REG_DWORD

Value: 0x01 ( default is 0 )

On Windows XP SP2:


Value Name: allowtgtsessionkey

Value Type: REG_DWORD

Value: 0x01

I had to create them both but yep they are correct on the 2k3 server and the XP SP2 client.

Okay I got past that. The problem was that I read somewhere that I was to enable “DES” encryption within the AD user settings. After disabling this I was able to get this out of the log:

Added server’'s keyKerberos Principal xmpp/ptldme-mngt.xxx.com@XXX.COMKey Version 2key EncryptionKey: keyType=23 keyBytes (hex dump)=


added Krb5Principal xmpp/ptldme-mngt.XXX.com@XXX.COM to Subject

Commit Succeeded

But I still get SASL error on the client.

Now I believe I resolved that!!

I disabled “allow this user trusted delegation” under delegation in AD user settings.

Once again I read somewhere to enable this…pffft shouldn’'t believe everything I read.

Seems to be working. I will be testing on some other users here soon.

Thanks for getting me this far SP!!

Happened again. Worked great for like 5 minutes and then it died. Frustrating.