SSO Problems

Since I do pay for enterprise forum support I might as well use it.

so I got sso working on my test server and then thought I was ready to

go on my new server. I used setspn on active directory to delete

existing spn bindings for the user and then created a new keytab. I

have already done this with the test server and recreated the keytab

and it worked fine. Now when I add the SSO stuff to my live server it

doesn’t work. the client

does have this error though in the warn.log file and it doesn’t mean

much to me:

Mar 16, 2008 10:18:57 PM org.jivesoftware.spark.util.log.Log warning

WARNING: Exception in Login:

not-authorized(401)

at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication .java:94)

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

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

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

at org.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:196)

at org.jivesoftware.LoginDialog$LoginPanel$1.construct(LoginDialog.java:594)

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

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

The only differences are my test server is 3.4.5 and my live server is

3.3.1. Also my live server has 3 valid dns names and when I do an nslookup it lists my chat name as 2nd, not sure if that makes a difference. if you would like to see my openfire.xml just let me know.

Help is much appreciates. this is now what I am seeing in my openfire logs:

2008.03.16 23:26:52 SaslException

javax.security.sasl.SaslException:

Failure to initialize security context [Caused by GSSException: No

valid credentials provided (Mechanism level: Attempt to obtain new

ACCEPT credentials failed!)]

at com.sun.security.sasl.gsskerb.GssKrb5Server.<init>(GssKrb5Server.java:95)

at com.sun.security.sasl.gsskerb.FactoryImpl.createSaslServer(FactoryImpl.java:67)

at javax.security.sasl.Sasl.createSaslServer(Sasl.java:491)

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(ConnectionHandl er.java:132)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:703)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:62)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:200)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :266)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:326)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

at java.lang.Thread.run(Thread.java:619)

Caused by: GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)

at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.ja va:87)

at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.jav a:111)

at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:178)

at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:384)

at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:42)

at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:139)

at com.sun.security.sasl.gsskerb.GssKrb5Server.<init>(GssKrb5Server.java:78)

… 19 more

Caused by: javax.security.auth.login.LoginException: KDC has no support for encryption type (14)

at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginMod ule.java:696)

at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)

at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)

at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)

at javax.security.auth.login.LoginContext.login(LoginContext.java:575)

at sun.security.jgss.GSSUtil.login(GSSUtil.java:246)

at sun.security.jgss.krb5.Krb5Util.getKeys(Krb5Util.java:185)

at sun.security.jgss.krb5.Krb5AcceptCredential$1.run(Krb5AcceptCredential.java:82)

at java.security.AccessController.doPrivileged(Native Method)

at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.ja va:79)

at java.security.AccessController.doPrivileged(Native Method)

at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.ja va:79)

… 25 more

Caused by: KrbException: KDC has no support for encryption type (14)

at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:66)

at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:449)

at sun.security.krb5.Credentials.sendASRequest(Credentials.java:406)

at sun.security.krb5.Credentials.acquireTGT(Credentials.java:355)

avax.security.sasl.SaslException: Failure to initialize security

context [Caused by GSSException: No valid credentials provided

(Mechanism level: Attempt to obtain new ACCEPT credentials failed!)]

at com.sun.security.sasl.gsskerb.GssKrb5Server.<init>(GssKrb5Server.java:95)

at com.sun.security.sasl.gsskerb.FactoryImpl.createSaslServer(FactoryImpl.java:67)

at javax.security.sasl.Sasl.createSaslServer(Sasl.java:491)

at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java :220)

I am using this thread http://www.igniterealtime.org/community/docs/DOC-1060
user-roster-edit.patch (738 Bytes)

The two things that stand out from a trouble shooting perspective is that the version numbers are pretty different, and there are 3 domain names.

I seem to remember 3.3.* having some weird issues with security settings that were corrected in 3.4.5, if at all possible I’d recommend trying to upgrade your live server to the latest version.

I’ve seen a lot of issues when a server has more than one domain name or the domain name resolves to the wrong NIC. Packets are routed based on the domain name so I’m not sure how having 3 different domains could effect the implementation of your SSO, but it’s something to consider.

it didn’t even dawn on me about the version differences when I was testing. as for the different dns names, I have apache hosting different names and all resolve to the same ip. this is also only internal. I will see about upgrading, I was kinda wanting to wait for 3.5, which may not be far off. thanks for the help, any other ideas?

The issue looks like the server is not able to obtain credentials. That bit has not changed in Openfire since I first got GSSAPI support working. If I had to guess, I would say your test server had Java 1.6, and your prod server has 1.5. Can you double check that? If you are running with 1.5 on the server, try installing the Unlimited Strength JCE Policy Files and restart the service, that might be sufficient.

Also, what OS are the two servers running on?

both servers are debian stable, both have java se runtime environment (build 1.6.0_02-ea-b02).

I went back to my test server and tried to get 3.3.1 working and it won’t authenticate. I made a db backup and then upgraded 3.3.1 on my test server to 3.4.5 and tested kerberos and it works. so now I know I have a valid keytab for kerberos and a valid config. so I backed up the db again and restored 3.3.1 and brought it back up with the same keytab and identical configs with only the paths different (since I have 3.3.1 and 3.4.5 in physically different dirs) and 3.3.1 won’t authenticate. at this point the only difference is the openfire version.

I went back over my config vs http://www.igniterealtime.org/community/docs/DOC-1060 (thanks btw)

and found this

Openfire Versions

Provider Names

3.3.0 and prior

org.jivesoftware.openfire.sasl.LazyAuthorizationProvider

3.3.1 and later

org.jivesoftware.openfire.sasl.LooseAuthorizationPolicy

trunk (nightly builds)

org.jivesoftware.openfire.auth.DefaultAuthorizsationPolicy

and how it differs from my config. is my testing on both 3.4.5 and 3.3.1 I was using LazyAuthorizationProvider. From the above I would think that wouldn’t have worked for either version but it was working for 3.4.5 and not 3.3.1. I changed that to LooseAut… and it now works with 3.3.1 and I will be putting this on my live server tonight.

I will also mention that when I use the ktpass that was already installed on my dc it wasn’t producing valid keytabs, when I used the ktpass from the client tools I installed on my computer (copied over to my dc) it works. go figure. I will try tonight and update. thanks for you help.

I am back to this not working. it doesn’t work in the slightest on my live server, nothing related to a sso login ever gets logged on the openfire logs. I am wondering about the debug turned on twice, its turned on once in the end of my config and then once in the sasl config. I removed the one from the sasl config and still didn’t see anything in the logs. the only thing I am seeing is this in my client logs:

Mar 18, 2008 9:55:02 PM org.jivesoftware.spark.util.log.Log warning

WARNING: Exception in Login:

not-authorized(401)

at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication .java:94)

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

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

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

at org.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:196)

at org.jivesoftware.LoginDialog$LoginPanel$1.construct(LoginDialog.java:594)

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

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

help is greatly appreciated.

I just now noticed this error in warn.log that is just happening, not concurrent with login attempts and I don’t know if its related.

2008.03.18 22:14:56 Closing session due to incorrect hostname in stream header. Host: chat.biltmore.com. Connection: org.jivesoftware.openfire.net.SocketConnection@d9973a socket: Socket[http://addr=/10.72.1.54,port=37269,localport=5269] session: null

I am also seeing this in the debug.log where openfire seems to ignore my resolv.conf all together and try to figure out name servers on its own. any idea where it gets that info from and why its trying my tld instead of the subdomain since I never actually specify chat.biltmore.com as the hostname, just chat and it assumed the rest from where?

Error trying to connect to remote server: biltmore.com(DNS lookup: biltmore.com:5269)

java.net.SocketTimeoutException: connect timed out

at java.net.PlainSocketImpl.socketConnect(Native Method)

at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)

at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)

at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)

at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)

at java.net.Socket.connect(Socket.java:518)

at org.jivesoftware.openfire.session.OutgoingServerSession.createOutgoingSession(O utgoingServerSession.java:253)

at org.jivesoftware.openfire.session.OutgoingServerSession.authenticateDomain(Outg oingServerSession.java:184)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:199)

at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:184)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

at java.lang.Thread.run(Thread.java:619)

I believe the problem is that the server has multiple names assigned to the same ip. I added some test dns names for my test server and it broke sso for the test server. for anyone else reading this, I have found a fix or workaround or whatever you want to call it. I am using debian, so I created an alias for my network interface http://www.cyberciti.biz/faq/bind-alias-range-of-ip-address-in-linux/ and then I set openfire to liston on eth0 only. I changed the dns entries for the other names and then rebooted the server (for good measure). server came up and brought up both eth0 and eth0:1 and now sso is working as well as all of my other services. I will be putting this on my live server tonight and thanks for the help and I will report back if it doesn’t fix it.

DNS correctness is very important to Kerberos. When a client wants to connect to a service, it determines what name to use by doing a reverse lookup on the IP its connecting to, not the name you gave it. Java dosnt have very good support for multi-homed systems yet, so you need to make sure you are using the correct name for things if other interfaces exist on the system.