Pidgin XMPP and Kerberos

clockwork at clockwork at
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/ So IMHO the connect server should override the Domain in
this respect.

On 2/21/08, Etan Reisner <deryni at pidgin> wrote:
> On Thu, Feb 21, 2008 at 05:40:35PM -0500, clockwork at wrote:
> > So I have an openfire server, and I'm using pidgin on the client side
> with
> > kerberos authentication. However when using kerberos tickets to
> authenticate
> > with pidgin I run into a bit of a conflict. The pidgin config is as
> follows:
> >
> > Domain:
> > Connect Server:
> >
> > Using a kerberos password works. Using a kerberos ticket however fails
> with
> > the following error: (garnered from pidgin -d)
> >
> > sasl: GSSAPI Error: Unspecified GSS failure.  Minor code may provide
> more
> > 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
> ticket
> > 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 and
> user at 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).
>     -Etan
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Support mailing list