Which is your Openfire version?
What does your connection configuration look like?

Why does it matter what OpenFire version I am running (it's 3.9.3, BTW)? This is an issue with the plugin.

The connection configuration is very simple:
JabberID (username@FQDN) and Password are set
Accept all SSL/TLS certificates is set
Expose Presence is set

I was able to find the file that it is trying to load, using lsof and strace. Java is trying to load '/gss.conf'. I even tracked down the class that is trying to do the loading, org.jivesoftware.smack.sasl which does a relative path load.

So, I tried to create a gss.conf file based on what I can glean from http://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
but I really just want to proceed with PLAIN auth and not use GSSAPI.

There should be a way to bypass GSSAPI authentication and just use PLAIN auth or fail to PLAIN auth when GSSAPI fails.

It does matter because bugs are many times only manifest themselves when specific versions are used

I see.

Alternately, how do I configure the gss.conf file so that I can properly get a ticket without having to "kinit" as the jenkins user? My keberos client config is in the standard /etc/krb5.conf location.

hi kutzi,

i've been debugging this issue with dylan.

we were able to work around the problem by downgrading the plugin version to 1.25 and unchecking "use SASL authentication" in the jenkins/jabber configuration. by downgrading, we removed the dependency on smack 4. afaik, smack 4 can only use sasl auth, and sasl auth is the general cause of our issue. "PLAIN"/simple auth works just fine.

we would like to stay on top of the latest version of jenkins and all of our plugins, so obviously, this is a non-optimal workaround.

i accept the fact that upgrading to the latest version may mean that we are forced to use sasl auth, in which case we would need to resolve the errors in the attached debug output. also, as dylan mentioned, we were able to eventually get the jenkins user authenticated to our openfire server using sasl auth and the latest jabber plugin (1.34), but with two HUGE caveats:

• to clear the error in the attached debug output, we had to create a file called /gss.conf and give it some contents that we snagged from another bug report on the web. there is NO documentation on where this gss.conf file should be located, how to configure its location, or what its contents should be. we needed to strace the jenkins server to even figure out where jenkins was looking for it, and we have no idea what the contents of the file mean or what this file is used for.
• it's necessary to manually kinit to please gssapi. we provide the password for the jenkins principal to the jabber plugin, so this shouldn't be necessary; a ticket should be automatically created when jenkins successfully auths to the openfire server.

so though this bug report was originally filed for the first issue, the second one seems very closely related. let us know if you think a new bug report should be opened for that issue.

thanks,

jay

Thanks for debugging this issue.
I'm sorry, but I don't understand which second issue you see. Basically I can see one issue here:
that setting up GSSAPI authentication with the current plugin seems to be a PITA, right?

Without having looked into the details this seems more like a Smack API or even JRE issue itself.

Kutzi,
Where should we go from here? Unfortunately, the way that this problem manifests itself ("gss.conf file not found") does not clearly point to a resolution. Even if we say, "This is an issue with Smack" it will prevent many users from using your plugin. Additional documentation (on your GitHub page), providing a default gss.conf file with the plugin, and/or opening a bug report for Smack is probably warranted.

Also, can you point me to a clear and concise resource for configuring GSSAPI authentication for Java, like the Smack library expects? I have been searching for two days and have only found fragmented pieces of information here and there, which are extremely difficult to piece together.

Thanks, again, for your assistance. I believe that this plugin will be extremely valuable to my team.

Dylan,
I understand that the situation for GSSAPI authentication is far from being satisfactory.
The thing is that you probably know now - after debugging the issue on your side - infinitely more about how to configure it than I do.
So if you could document your findings on the Wiki, this would be great. If you have other suggestions on how to improve default user behaviour reagrding this issue with the plugin, I'm also happy to hear it.

Sorry, I do know basically nothing about GSSAPI. If you're looking for documentation/help, the Smack API site is probably a better location.