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.

Do you have anything in your gss.conf file? Does this plugin work for you?

I'm not using the plugin currently. When I used it last time several month ago, I didn't need to configure a gss.conf file.

kutzi,

the jabber plugin was changed to use the smack 4 library in october of last year. have you used this plugin since then? we are only seeing this issue with plugin version >= 1.26, which is when the dependency on smack 4 was introduced.

>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.

the official smack documentation doesn't have any information about configuring gss.conf or any krb5 configuration in general. smack docs only talk about the java api.

since the jabber plugin only supports gssapi auth (since smack 4 only supports gssapi auth), i'm not sure i understand how it's possible to use or develop this plugin without needing to configure or touch gssapi.

jay

No, I haven't used in since then. Maybe some short tests against a testserver.

Kutzi,
Do you mind installing and testing the latest version of the plugin? I would greatly appreciate to see your results.

Jay, I don't know why you think that smack 4 only supports gssapi. I can see e.g. here several other supported auths: http://www.igniterealtime.org/builds/smack/docs/4.0.6/javadoc/org/jivesoftware/smack/sasl/SASLMechanism.html

Maybe I'll find some time to test this in the next days but cannot promise anything.
The plugin has a reported 2000 installations. I'm pretty confidend at least some of them are at a reasonable new version and don't have the problems you have

Also, I don't understand why you keep pressing this issue so much. I thought you had figured out a way to authenticate even with the latest version?

And again: the smack forum would be a better place to ask about xmpp/smack authentication details!

> Jay, I don't know why you think that smack 4 only supports gssapi. I can see e.g. here several other supported auths: http://www.igniterealtime.org/builds/smack/docs/4.0.6/javadoc/org/jivesoftware/smack/sasl/SASLMechanism.html

i apologize - i meant that smack 4 only supports sasl auth. non-sasl (a.k.a. simple) auth works, but is not available in smack 4.

where do you see the other supported auths? and how would i switch between them? (neither of us are java devs so it's a little bit challenging for us to grok java api docs)

> Also, I don't understand why you keep pressing this issue so much. I thought you had figured out a way to authenticate even with the latest version?

almost, but not quite. we found a manual way to authenticate, and the jenkins user would only be auth'd as long as the kerb ticket is valid. effectively, this means we need to manually authenticate the jenkins user once a day, which isn't acceptable. so really, we found a crummy workaround, but this doesn't resolve this bug report, and we're not entirely sure why or how our workaround solves the issue, or if it's really just a band-aid over a different problem.

personally, i don't believe the behavior described in this bug report ("gss.conf not found" exception) matches the expected behavior for this plugin (if i've supplied my jabber id and password to the jabber plugin, it should have all the information it needs - why is it complaining about something called "gss.conf"?).

> And again: the smack forum would be a better place to ask about xmpp/smack authentication details!

okay, i accept that this may be an upstream issue, but it seems to me that this kind of error shouldn't bubble up to the downstream consumer... i shouldn't need to know anything about gssapi in order to auth to an xmpp server through a jenkins plugin. i feel like that's really the crux of the issue.

kutzi, thanks for your time and help with this issue. i hope my little diatribe here clarifies why we keep bugging you

We're having the same issue. Since nobody seems to be willing to fix the bug, jay/dylan. Would you share an example gss.conf and the location to put the gss.conf as workaround?

After spending almost two days using Procmon on Windows and Tomcat 8 I found that gss.conf should be placed in ${catalina.base} of your Tomcat installation.
Now I am trying to find out WHAT should be entered into gss.conf to work. Standard gss.conf with keytab file doesn't work.
Since out XMPP Server offers GSSAPI and PLAIN, it would be extremely helpful to have a setting in the Jabber Plugin on how to connect to the server, since the Enable SASL authentication Checkbox isn't displayed anymore (There exists also a ticket for that issue).

Edit:
Here is my gss.conf which was working for me after I set the proper RegKey

RegKey
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"AllowTGTSessionKey"=dword:00000001

gss.conf

// Some comments here
com.sun.security.jgss.accept {  
    com.sun.security.auth.module.Krb5LoginModule required 
	useTicketCache=true
	client=TRUE;
};

Could you try the plugin from the latest master, which is now using Smack 4.1.9,  by issueing "mvn package" and report back if the issue still exists?