qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Failures when using SASL with GSSAPI on C++ broker
Date Mon, 01 Nov 2010 20:59:31 GMT
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" <woogie@eseri.com> 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:users-subscribe@qpid.apache.org

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message