Pidgin XMPP and Kerberos
deryni at pidgin
Thu Feb 21 17:44:03 EST 2008
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 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: domain.com
> Connect Server: im.foor.domain.com
> 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 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).
More information about the Support