Pidgin XMPP and Kerberos
clockwork at sigsys.org
clockwork at sigsys.org
Thu Feb 21 17:55:23 EST 2008
Cant say what the expected behavior is regarding the user ID's, but that
isnt the problem I'm running into. :-)
The trick is AFAIK there is no such thing as a generic ticket in kerberos
the tickets are always tied to hosts (ie I dont think you can have ticket
for xmpp/foo.com). So IMHO the connect server should override the Domain in
On 2/21/08, Etan Reisner <deryni at pidgin> wrote:
> On Thu, Feb 21, 2008 at 05:40:35PM -0500, clockwork at sigsys.org wrote:
> > So I have an openfire server, and I'm using pidgin on the client side
> > kerberos authentication. However when using kerberos tickets to
> > with pidgin I run into a bit of a conflict. The pidgin config is as
> > Domain: domain.com
> > Connect Server: im.foor.domain.com
> > Using a kerberos password works. Using a kerberos ticket however fails
> > the following error: (garnered from pidgin -d)
> > sasl: GSSAPI Error: Unspecified GSS failure. Minor code may provide
> > information (Server not found in Kerberos database)
> > Now if I reverse the pidgin config so that the Domain is the hosts
> fqdn and
> > leave the connect server blank everything works peachy keen. This seems
> > horribly backwards since that means pidgin is using Domain for the
> > request instead of connect server which is IMHO the expected behavior.
> > So is this indeed the expected behavior ?
> I'm unable to comment on the Kerberos specific bits of this, but if you
> are leaving the connect server blank pidgin needs to use *something* to
> request the ticket and as such only has the domain to do so. So that part
> at least seems correct to me.
> As to whether pidgin should be using the domain or the connect server to
> acquire the ticket when both are specified I'm unable to really comment,
> though I would think probably the domain as the connect server is really
> just an implementation detail of where the connection occurs to and not
> the service being provided. But someone who actually understands Kerberos
> and GSSAPI would need to comment on this to be sure (I'm sure I could go
> look but I don't have the time right now).
> I'm more puzzled as to why both user at domain.com and
> user at im.foor.domain.com are acceptable JIDs to your server (unless it
> intentionally is set up to serve both of those domains), though thinking
> about this it may just be an openfire bug as I think I have seem the same
> lack of caring on our internal openfire server at work as well (though I
> didn't think much about it at the time).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Support