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 this respect. On 2/21/08, Etan Reisner <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 21, 2008 at 05:40:35PM -0500, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] and > [EMAIL PROTECTED] 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 >
_______________________________________________ Support mailing list [email protected] http://pidgin.im/cgi-bin/mailman/listinfo/support
