And my clients are running Spark 2.5.8 on Windows XP
This is my second day trying to get SSO to work, but I’m still getting nothing .
I had Openfire up and running, and could log in no problem using AD. I made the changes as suggested by the SSO guide, and now I can’t log in even with just putting in my regular credentials. Everytime I log on my server, it gives me the setup guide for Openfire, and then when I finish, it just makes me do it again, and it keeps looping!
Would it be possible for someone with a linux server to post a copy of their openfire.xml file so I can see what I’m doing wrong, as I believe this is where my issue is coming from at the moment.
I went through the documentation and you’re files, and all seemed correct, for the parts that match up, as we’re running the Openfire on different O/Ss.
If someone that is running the same multiplatform setup as me, and they could put their files up, that would be great.
I think what I’ll try to do for the moment is get SSO running on an all windows setup, and then maybe learn how everything works a little better that way.
The documents listed are all good. The setup you describe has been tested by many, too. Are you getting any errors in any of the logs that we might be able to help you with?
2008.09.04 19:00:35 [org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHand ler.java:135)
] Closing connection due to error while processing message:
PASSWORD
java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(Unknown Source)
at org.jivesoftware.openfire.sasl.SaslServerPlainImpl.evaluateResponse(SaslServerP lainImpl.java:109)
at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java :245)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:160)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:133)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Unknown Source)
So its the top part that seems like the problem. It seems like its problem is sasl, but I have that in my openfire.xml file, so I’m a little lost.
You might want to edit that post and change your password right away, since you just posted it. The part that starts AHR… thats your password easy enough for anyone to get.
It appears the client is trying to use the PLAIN sasl mechanism, which means SSO is not even being tried. Something weird did happen, though, since an exception should not have been thrown for trying PLAIN. What is in the client logs? Also, can you turn on debugging in openfire?
When I turned on Debugging in Openfire, the only dbug error that I received was:
“2008.09.05 11:26:08 NIOConnection: startTLS: using c2s”
Is there something else specail that I have to edit on the client side? I have it so it allows me to choose SSO, and thats what it sais when I’m trying to log in…I’ve changed the registry as well, so I’m confused on why it would just try the plain text.
As for the password, I changed it, but i’m only using a test account, so it doesn’t really matter, and the servers aren’t connected to the internet. But thanks for the heads up.
From the client side, in the debugger window, I received the error:
After multiple carefull inspections, I fix one problem. My section got stuck in the section…
So that cleared up one problem, which now brings me to my next one, which is that now when I try to log on, I don’t seem to be authorized. I get the following error from my client debugger durring logon:
USERNAME
spark
On the Openfire side, I get the following:
2008.09.05 17:13:04 ConnectionHandler:
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(Unknown Source)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at sun.nio.ch.IOUtil.read(Unknown Source)
at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.j ava:218)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcesso r.java:198)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProce ssor.java:45)
at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProce ssor.java:485)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
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)
2008.09.05 17:13:07 NIOConnection: startTLS: using c2s
In the client debug window, take a look at what was sent to you from the server. The client is choosing PLAIN because it is the only acceptable method it determined. This could be because the server is not sending GSSAPI as an option, or the client does not have the credentials to use GSSAPI.
If the server is sending GSSAPI as an option ( you can remove PLAIN if you want to not allow it, by the way) then take a look in the client for your SSO options. Are there any messages about what username it is going to attempt?
A new issue, that might be the cause of above ones.
I just noticed that whenever I start up Openfire, my openfire.xml has all the settings in the section set back to default, and even my GSSAPI section erased! I’ll have the Openfire.xml file setup the way that it should be, save the file, reopen the file to make sure everything is still there, then I’ll run Openfire, and then everything gets removed
Anyone have any idea why this would happen?
Is there another file thats editing the Openfire.xml file that could be doing this?
In the admin console, look at all your properties- you will find them there. They get migrated out of the config file into the database now (not sure what version that started happening)
Below is a section of my server properties from the Admin Console
sasl.gssapi.debug
true
sasl.gssapi.useSubjectCredsOnly
false
sasl.mechs
GSSAPI
And here is my openfire.xml
Use true to turn on debugging information. This adds a lot of noise to your
log files, but it can help you spot problems sooner in the initial setup.
Specify the location of the GSSAPI configuration file you edited.
Sets the system property with the same name. You'll probably want "false" here
(the default). For more details,
see [http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/package-summary.html]
Some of the other settings, such as my domain, make it into the xml file, but not the noted above section.
I find it kinda of odd that only parts of the openfire.xml file gets updated, while the rest gets set back to default, but I’m sure theres probably a reason for it.
Anyways, as to Slushpuppie question, I’m not sure if the client is sending the correct user name.
There are only 4 packets in total that are exchanged, which are the following:
From the Client-
testuser
From the Client-
testuser
spark
From the Server-
testuser
From the Server-
testuser
spark
It’s that last packet that has me confused, as I’m not sure if its supposed to show the password there, because it does when I enter the passwork in the client manually, and the line first line in the last packet is also different, from when I don’t use SSO. If I don’t use SSO, I get , but again, this all might be from using SSO, and that number represents more. Any thoughts?
The client has reverted back to using IQ auth, which means none of the presented SASL options were acceptable. Either your server is (still) not advertising GSSAPI, or the client dosnt think it can use it. In the client when you go to the SSO tab, what do you see?
I tried the krb5.ini file, and when trying to log into my spark client, the following error shows up on the Openfire server:
Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is C:/Program Files/Openfire/resources/jabber.keytab refreshKrb5Config is false principal is xmpp/openfireserver.domain.com@DOMAIN.COM tryFirstPass is false useFirstPass is false storePass is false clearPass is false
principal’s key obtained from the keytab
Acquire TGT using AS Exchange
[Krb5LoginModule] authentication failed
Cannot get kdc for realm DOMAIN.COM
I can ping domainpdc.domain.com, and I have also tried entering in the IP address, instead of the name, but I got same result
Any suggestions on this error?
Again, thanks for all your help on the setting up of this! The response time that you guys have is phenominal, and I’m sure everyone on here appriciates it!
The redacting of your domain name, realm, and host names is going to be troublesome from this point forward. The errors you are getting are tied very close to what is in DNS, and Kerberos is VERY picky about such things. So you either need to repost that last error unmodified, or if you prefer you can send me the errors in private (will take longer to diagnose in private, though). Without getting the actual names all I can suggest is you re-read the documentation and make double/triple sure that things are correct. CNAME’s more often than not cause problems, so make sure you are not listing aliases anywhere.