Hi Greg, I've tried to repro the problem you are seeing on my local machine using SVN revision 1029793... no avail.
For my client, I am using qpid-perftest on the same physical system as I am running qpidd - can you try that and see if it works? E.g: qpid/cpp/src/tests/qpid-perftest -b $FQDN --mechanism GSSAPI --username $USERNAME --tx 1 --count 1 fyi, I'm running a simple broker setup - a single broker directly from my repo: ./qpidd --auth yes --realm $REALM let me know what you find, -K ----- "Wolgemuth Greg" <[email protected]> wrote: > Hi everyone > > I'm trying to use GSSAPI for authentication between clients and > brokers, > and I'm consistently running into errors. > > I'm running two Fedora 13 machines, with up-to-date packages. I've > tested the Kerberos system on both boxes, and have no problems > kiniting, > or using other GSSAPI authenticated services (postgres, for one > example). I've double-checked the DNS system, and all hostnames and > IPs > are matching up correctly. One box runs qpidd, the other runs the > clients I've written. The qpidd has been built from trunk, SVN > revision > 1029755. > > The error I see come up on the client side is: > > qpid.messaging.exceptions.ConnectionError: connection-forced: > Authentication failed(320) > > On the other side, at the qpidd I see the following pop up in the > log: > > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug RECV > [10.80.0.51:38798] INIT(0-10) > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug External > ssf=0 and auth= > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug min_ssf: > 0, max_ssf: 256, external_ssf: 0 > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 info SASL: > Mechanism list: GSSAPI > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug SASL: > Starting authentication with mechanism: GSSAPI > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 warning Failed > to retrieve sasl username > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 info SASL: > Authentication failed (no username available):SASL(-6): can't request > info until later in exchange: Information that was requested is not > yet available. > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug Exception > constructed: Authentication failed > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 warning Failed > to retrieve sasl username > Nov 1 20:16:22 fed1 qpidd[13325]: 2010-11-01 20:16:22 debug > DISCONNECTED [10.80.0.51:38798] > > I see the same problem when I try to use `qpid-python-test` instead of > my own clients. > > My client is using a slightly older version of trunk (about two weeks > old), but I've got a hunch this is a problem on the daemon side. > When I examine the list of keytabs left on the client, I can see that > it has established communication with the daemon. > Examining the logs on my KDC shows everything looks normal, as well. > > The frustrating part of this is that everything was working last week, > and nothing changed in my environment in the interim in the meantime. > > Thanks, > > Greg > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
