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.
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/dev008.tcs.com@TCS.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
principal is xmpp/dev008.tcs.com@TCS.COM
EncryptionKey: keyType=23 keyBytes (hex dump)=0000: B3 60 6A A7 AE BA 09 C7 06 CC 8D C3 1E ED 34 6C .`j…4l
Added server’s keyKerberos Principal xmpp/dev008.tcs.com@TCS.COMKey Version 14key EncryptionKey: keyType=23 keyBytes (hex dump)=
0000: B3 60 6A A7 AE BA 09 C7 06 CC 8D C3 1E ED 34 6C .`j…4l
[Krb5LoginModule] added Krb5Principal xmpp/dev008.tcs.com@TCS.COM to Subject
Commit Succeeded
From the info log on Openfire, I get:
User Login Failed. Failure to initialize security context
*I’ve slightly changed the above keys as I wasn’t sure if they were of security values.
some things to also consider when doing sso, does the time on the chat server and your clients match the dc? as picky as kerberos is about dns, its as picky about the time
do you have kerberos tools installed on your openfire server?
will it always give the same result or do you have multiple names out there? This caused me much grief.
**edit, I also had problems with the ktpass included on 2003. I believe I had to use an older version, it doesn’t list a version but it was created in 1999. I have no idea what the difference is but the one on 2003 server didn’t work for me (could have been coincedence)
