powered by Jive Software

Openfire server crashed, moved to new server and now SSO fails

Typical, we had SSO (Windows AD, OpenFire 3.3.1, Spark 2.5.6, Win XP SP2) working fine for approx 30 users and yesterday suffered a catastrophic server crash. This wiped out the database and application (all on the same server) Luckily everything was backed up so I did the following:

old server: athena.emedia.co.uk, Win2003 Sp1, 4GB RAM,

new server: vm-athena.emedia.co.uk, Win2003 R2, 1Gb RAM

Built new server running, MS SQL 2000 sp4, restored program files\openfire folder, re-installed openfire service, restored database.

Restarted the app. First thing I noticed was that it detected the server name as 127.0.0.1 within OpenFire, set this to emedia.co.uk and all seemed fine. I then noticed all my groups had gone (weren’t they supposed to be in the database?) I recreated all the server side shared groups.

I was then able to manually log in using Spark with no other changes. However I could not log in via SSO.

OpenFire pulls all our users from Active Directory and about 3 months ago we got SSO working (after some pain)

I’ve now gone back through our SSO settings and followed the HowTo on this site but get the error: “Not Authorized” from Spark logs when trying to log in using SSO

I have copied the old AD user xmpp-athena to xmpp-vm-athena and set a new password

I have created a new jabber.keytab file using the command line:

ktpass -princ xmpp/vm-athena.emedia.co.uk@EMEDIA.CO.UK /mapuser xmpp-vm-athena -pass password -out jabber.keytab

all the DNS svr records pointed to im.emedia.co.uk which is a CNAME for vm-athena.emedia.co.uk, for good measure I’ve added a CNAME for the old server to point to the new server.

I have updated the GSSAPI.CONF file with the new principal details, as far as I can see I don’t think anything else needs to change.

What have I missed?

thanks

Steve
XMPPConnection.as (28800 Bytes)

A few more things we’ve done:

  1. Copied our krb5.ini to c:\windows on the server (same as the one all the clients have)

  2. set the registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\allowtgtsessio nkey to 0x1 on the server (already set on all the clients)

I haven’t touched the openfire.xml config file as I can’t see anything in there referencing the server name and this was all working before, same for the krb5.ini file

ok, bit of progress, I corrected the registry entry, server is different from XP, extra parameters folder, and I now actually get warnings logged in openfire

Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)

at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Unknown Source)

at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Unknown Source)

at sun.security.jgss.GSSManagerImpl.getCredentialElement(Unknown Source)

at sun.security.jgss.GSSCredentialImpl.add(Unknown Source)

at sun.security.jgss.GSSCredentialImpl.(Unknown Source)

at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)

… 20 more

Does that point towards a problem with the keytab?

warning log from server

Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Unknown Source)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Unknown Source)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(Unknown Source)
at sun.security.jgss.GSSCredentialImpl.add(Unknown Source)
at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source)
at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)
... 20 more
2007.10.19 13:38:28 SaslException
javax.security.sasl.SaslException: Failure to initialize security context [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)]
at com.sun.security.sasl.gsskerb.GssKrb5Server.<init>(Unknown Source)
at com.sun.security.sasl.gsskerb.FactoryImpl.createSaslServer(Unknown Source)
at javax.security.sasl.Sasl.createSaslServer(Unknown Source)
at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java:220)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:141)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:132)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:62)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:200)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:266)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:326)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Unknown Source)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Unknown Source)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(Unknown Source)
at sun.security.jgss.GSSCredentialImpl.add(Unknown Source)
at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source)
at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)
... 20 more

fixed it I read back through an old thread : here

and found out that this is the exact problem I had previosuly which was fixed by adding xmpp.fqdn into Openfire properties.

Just out of interest, why didn’t this get carried forward (even though I would have had to change it) to the new server, it was completely missing.

That setting, as well as the host name problem you had (xmpp.domain is the property name) are stored in the database. So something about your restore (of the database) must have not worked 100%, you may have lost other properties too.