powered by Jive Software

SSO HELP - Openfire.xml

Hey,

My Openfire 3.6.0a on a Linux server.

My Active Directory is on Windows Server 2003

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.

Thanks

I do not have a linux server but i do have this doc that may be of some help. My sample files are at the bottom of the doc.

http://www.igniterealtime.org/community/docs/DOC-1616

I’ll compare what I have to your examples and let you know where that puts me.

Thanks

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.

Thanks

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?

An error thats showing up is:

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:

<stream:stream to=“IP ADDRESS” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams” version=“1.0”>

<stream:stream to=“mydomain.com” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams” version=“1.0”>
PASSWORD

</stream:stream>

Hey,

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

Any ideas or suggestions?

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?

Hey,

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?

Thanks in advance for any help

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

Click to edit this property
Click to delete this property

sasl.gssapi.useSubjectCredsOnly

false

Click to edit this property
Click to delete this property

sasl.mechs

GSSAPI

Click to edit this property
Click to delete this property

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.

This what was moved to my database:

ScreenShot012.jpg

This is what is left in my openfire.xml:

DOMAIN.COM

Thanks for that Todd.

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?

Attached is a screenshot of just the SSO page.

Checked off is the SSO and below it are filled in my Realm, and KDC.

Thanks

I have yet to get those to work. I use the krb5.ini option with no issues.

Hey Todd,

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

my krb5.ini file is as follows

[libdefaults]
default_realm = DOMAIN.COM
noaddresses = true

[realms]
DOMAIN.COM ={
kdc = domainpdc.domain.com
default_domain = 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.